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ABSTRACT 


Information, and the knowledge gained from it, has been the key component to 
strategic planning since the earliest combat operations. Success in the Information Age is 
defined by the military’s ability to communicate effectively in a dynamic environment 
and share relevant information seamlessly. Sharing information is a critical element to 
understanding missions that employ the operational concept of Network-Centric 
Operations and Warfare (NCOW). Discovering valuable information is vital towards our 
capacity to predict and/or prevent circumstances in our current war against terrorist 
organizations. 

This thesis describes fundamental concepts of information sharing and 
information discovery. Through the use of a systems engineering approach, this thesis 
created a common vision of an information sharing and discovery (ISD) system, 
evaluates the role of ISD in network-centric systems (NCS), and discusses the 
relationship of NCS to NCOW. This study also employs the system architecture method 
to establish the operational concept of ISD systems; derive requirements for future 
acquisitions of ISD systems; analyze the interactions that ISD systems have with external 
systems; and establish a functional architecture for the ISD system. 

This research approach provides guidance for the development and integration of 
future ISD systems in order to meet the needs of future DoD NCS. 
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EXECUTIVE SUMMARY 


Since the time of the earliest war strategists, information—and the knowledge 
gained from it—has been the key component to successful military planning in combat 
operations. Today’s military professional still requires credible information in a very 
dynamic environment, and is also required to collaborate with counterparts distributed 
throughout the world. To be successful, our military must be able to communicate 
effectively and share relevant information seamlessly. This is not a simple task in 
today’s national defense environment. Success in the Information Age is defined by the 
Department of Defense’s (DoD) ability to adapt to changes due to the latest information 
technologies before our adversaries. To meet the unique challenges the Information Age 
presents the DoD is employing systems that are able to collect and present critical 
information to end-users efficiently. These systems—information sharing and discovery 
(ISD) systems—are crucial to military operations because our strategic plans are only as 
good as the information that it is composed of. The sharing of quality information is an 
especially important element in determining the success of missions that employ 
Network-Centric Operations (NCO) and Network-Centric Warfare (NCW) (Alberts, 
Garstka, and Stein 1999, 7). Discovering valuable information is vital towards our 
capacity to predict and/or prevent circumstances in our current war against terrorist 
organizations. 

In spite of the importance of information sharing and discovery, there is currently 
no specific guidance that identifies what ISD systems entail. There is an absence of basic 
elements of the systems engineering approach and design for ISD systems, such as: an 
operational concept; requirements; interface guidance; and functional architecture. 
Terms, definitions, and key concepts about the important elements of information sharing 
and information discovery are also lacking (and those that exist are not standardized); so, 
it is often hard for a user to understand what his or her service (i.e., information) can offer 
them. Furthermore, it is even more difficult for DoD acquisition professionals to acquire 
or develop ISD systems because of the mixing of DoD and industry terms and 
perceptions, and lack of systems design requirements. 
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This thesis assesses current ISD systems used in the DoD and surveys relevant 
commercial industry trends that may be useful in the military network-centric 
environment. A systems engineering approach is applied to determine what today’s 
military requires from information sharing and discovery systems to be valuable to 
Network-Centric Operations and Warfare (NCOW) and the varying mission sets of the 
military. The goal was to better understand the concept of an ISD system and introduce a 
generalized design for ISD systems that considers functions necessary for future military 
endeavors. 

To conduct this study, this thesis first presented a brief summary of the history of 
Network Centric Operations and the Network Centric Warfare model and its applications 
to current military doctrine. These concepts are summarized to show the importance of 
information sharing and information discovery to ongoing military strategic planning and 
to introduce the concept of “information superiority” as it applies to current military 
strategy. The concepts of the global information grid and net-centricity were also 
explored to highlight the role of information sharing and information discovery in 
network-centric systems. 

Next, an overview of ISD systems was given to explain the importance of 
information sharing and information discovery and to define these terms as the basis of 
this study. Information sharing and the recent attention this term has gained in recent 
years was discussed to give the audience background information and a context for this 
term. A discussion of the four core approaches for a network-centric system and their 
independent functions was explained to show how ISD systems are valuable to the 
network-centric environment. A general model illustrating how information sharing 
leads to information discovery showed that ISD systems reside in the top-down approach. 
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Figure 1. Information Sharing leads to Information Discovery 

Additionally, a wide array of current DoD system implementations was examined 
and discussed to give the audience examples of current tools and services that are 
available to warfighters. Upcoming industry trends were discussed to highlight the 
potential of future information sharing and discovery capabilities. 

Following the survey of NCOW’s history and the introduction of the operational 
concept of the ISD system, the thesis progressed through the system architectural 
methodology presented by Buede (Buede 2000, 20). The methodology begins with the 
refinement of the operational concept of the ISD system that was introduced in previous 
chapters. 
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Figure 2. Summary of originating requirements development (From Buede 1999, 159) 

An external system diagram for the ISD system was created to introduce the 
external systems that the ISD system must interface with. The external system diagram 
helped to bound the system design problem. Interactions between the ISD system and its 
external systems were traced to highlight the interface between the ISD system and other 
systems. 
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Figure 3. ISD System External Systems Diagram 

Next, the concept of the systems objective hierarchy addressed fundamental 
objectives for the ISD system. Finally, a summary of the different types of requirements 
categories was introduced and generalized requirements for future ISD systems were 
established. 

Following the introduction of ISD system requirements, the following chapter 
further designed the ISD system and presented key products created in the process of 
developing a functional architecture for the ISD system. The functions for the ISD 
system were identified and presented in the system functional hierarchy. 
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Figure 4. Top-level ISD System Functions 


Functional decompositions of each of the ISD system’s seven top-level functions 
was conducted. Finally, several requirement traceability matrices were introduced to 
track requirements to elements of the ISD system’s functional architecture. 

This thesis provides a top-level view of information sharing and discovery 
systems, which will enable future acquirers to be familiar with information sharing and 
discovery requirements. This study will allow DoD acquisition professionals to make 
informed decisions about future network-centric systems and their information sharing 
and discovery elements. It will also familiarize network-centric system users with the 
tools they are equipped with and allow them to understand which functional features of 
ISD systems are useful to their current operations. 

This thesis, its systems engineering approach, and its conclusions, provide 
numerous areas of potential study and can assist in the development and integration of 
future ISD systems for use in network-centric systems, and in the needs of future military 
forces. 
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I. INTRODUCTION 

In your thirst for knowledge, be sure not to drown in all the information. 

-Anthony J. DAngelo (The College Blue Book) 

This chapter introduces background information about the important role that 
information plays in today’s military environment and discusses the need for information 
sharing and discovery systems. The author’s personal motivation behind choosing this 
particular research subject is provided. The purpose of the study and the research 
questions that were undertaken are also introduced. The scope and methodology of the 
research is outlined to aid in the organization of the thesis. 

A. BACKGROUND 

Since the time of the earliest war strategists, information—and the knowledge 
gained from it—has been the key component to successful military planning and 
operations. Circumstances in our present military are not very different. We still 
recognize the value of credible information, however, today’s military professional is 
now required to collaborate with counterparts distributed throughout the world and is 
expected to keep abreast of a very dynamic environment. To be successful, our military 
must be able to communicate effectively and share relevant information seamlessly. This 
is not a simple task in today’s national defense environment. The Information Age is the 
period following the Industrial Age which has been defined by widespread access to 
information primarily due to information technology (United States Department of 
Defense Office of Force Transformation 2005). It has introduced an entirely new set of 
conditions that must be met in order to remain competitive against our adversaries. To 
meet the unique challenges the Information Age presents, the Department of Defense 
(DoD), and industry alike, is employing systems that are able to collect and present 
critical information to end-users efficiently. These systems—information sharing and 
discovery (ISD) systems—are crucial to military operations because our strategic plans 
are only as good as the information that it is composed of. The sharing of quality 


1 



information is an especially important element in determining the success of missions 
that employ Network-Centric Operations (NCO) and Network-Centric Warfare (NCW) 
(Alberts, Garstka, and Stein 1999, 7). 

In spite of the importance of information sharing and discovery, the problem 
exists in which there is currently no specific guidance that identifies what ISD systems 
entail. There is an absence of basic elements of the systems engineering approach and 
design for ISD systems, such as: an operational concept; requirements; interface 
guidance; and functional architecture. Terms, definitions, and key concepts about the 
important elements of information sharing and information discovery are also lacking 
(and those that exist are not standardized); so, it is often hard for a user to understand 
what his or her service (i.e., information) can offer them. Furthermore, it is even more 
difficult for DoD acquisition professionals to acquire or develop ISD systems because of 
the mixing of DoD and industry terms and perceptions, and lack of systems design 
requirements. 

This thesis assesses current ISD systems used in the DoD and surveys relevant 
commercial industry trends that may be useful in the military environment. This study 
also discusses the need for ISD systems to support operations in a network-centric 
environment. Finally, this thesis uses a systems engineering approach to introduce the 
design of an ISD system for use as guidance in future development and acquisition. 

B. PERSONAL MOTIVATION 

In late 2005, I was working as an action officer in the Current Operations (N31) 
shop of the Commander, U.S. Pacific Fleet (COMPACFLT). I had been in the job for 
almost six months at this point, and I was quickly learning the demands were great— 
especially since I was the only Lieutenant in the shop full of Commanders! A significant 
part of my job was to answer Requests for Information (RFIs) concerning surface 
operations in the Pacific fleet. These information requests varied in scope and I was 
assigned to find information, expeditiously, to answer the tasking of the directorate 
leaders. After some trial and error, and with some turnover from my predecessor, I was 
surprised to find that the easiest and fastest way for me to find the information was to use 
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a search engine, such as Google, as a starting point for information. I would “Google” a 
term or phrase relating to the inquiry and, depending on the results of the search; I would 
find other resources to examine. In the cases where it was a classified matter, I used 
search engines similar to Google on the classified Secret Internet Protocol Router 
Network (SIPRNet). Often, I would have information sources that conflicted directly 
with each other and would have to find a way to resolve the difference in information 
quickly. This entire process was very different from what I was taught in my previous 
billet as a naval nuclear propulsion engineer aboard a nuclear aircraft carrier. There, the 
bulk of our information came from a set of Reactor Plant Manuals (RPMs) and Steam 
Plant Manuals (SPMs). Changes to these references were rare, so watchstanders were 
very certain of the information from these manuals to guide our operations in the reactor 
plant. It highlighted a very large contrast, to go from very few sources of dependable 
information to an infinite source of references with varying assurances on the quality of 
information. 

My biggest assignment during the COMPACFLT tour came in early 2006, when 
my shop was tasked with planning the USNS Mercy deployment as a follow-up to 
Operation Unified Assistance, the previous year’s response to the Indian Ocean tsunami. 
This was a highly visible and wide-reaching project that required intense coordination 
with defense assets, as well as Non-Government Organizations (NGOs). Planning started 
almost a year prior to the deployment because this type of mission was unprecedented. 
The USNS Mercy, a hospital ship, had only been deployed during crisis situations—there 
had never been a humanitarian assistance mission of this scope, and that was built on 
multifaceted international partnerships (Roughead 2009). 

When it was time to start coordinating with participants approximately six months 
prior to the deployment date, information was flowing, but not all participants were “in 
the loop.” There were copious amounts of information, and it was all one could do to 
keep abreast of the deployment preparation issues that had to be resolved. I found myself 
wondering if there was a better way to handle the information amongst the group—the 
network—of deployment planners. I realized that information needed to be shared in an 
organized (though not necessarily formal) manner. Then, the pertinent and reliable 
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information, needed to be diseovered and vetted to the right leadership so that decisions 
could be made and action could be taken to progress the planning. 

Great things happened during the USNS Mercy 2006 deployment—it was an 
immense success, and the mission was even carried into the next year with a different 
naval platform. Many would ask: if the deployment went so well, why is there a need to 
improve information sharing among deployment planners? It is true that many military 
missions are planned under the same circumstances—most times the result is success, 
and sometimes there are severe lessons to be learned. In whichever camp one resides, I 
suggest that my lessons from the lack of an information sharing and discovery structure 
can be applied to the greater scheme, and a larger network. Information, and the 
knowledge gleaned from it, enables action to occur (Nissen 2006, 20). The Information 
Age is bittersweet because data is in abundance, but this does not mean that information 
is shared efficiently. Timely and reliable information is essential to successful 
operations, especially in the military profession. Therefore, it is essential that we identify 
the correct tools to share relevant information and distribute them to our warfighters. Our 
military success is dependent on getting the correct information before our adversaries. 

C. PURPOSE OF THE STUDY 

The purpose of this thesis is to apply a systems engineering approach to determine 
what today’s military requires from information sharing and discovery systems to be 
valuable to Network-Centric Operations and Warfare (NCOW). This thesis introduces a 
generalized design for ISD systems and considers potential functions that will be 
necessary for future military endeavors. A wide array of current military system 
implementations is examined and discussed. ISD topics that are addressed include 
network communications, Web-enabled services, collaborative technologies, data 
management, information discovery, service-oriented architecture, enterprise services, 
and the evaluation process that is inherent in bringing these programs to the warfighter. 
To avoid too broad of a study, the thesis assumes that the audience understands the 
fundamentals of computer networking and communications, and specific technical details 
about network sensors and distributed systems is omitted. 
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This top-level view of information sharing and discovery systems allows future 
acquirers to be familiar with NCOW information sharing and discovery requirements. 
This study enables DoD acquisition professionals to make informed decisions about 
future network-centric systems and their information sharing and discovery elements. 
This thesis also familiarizes network-centric system users with the tools they are 
equipped with and allows them to understand which functional features of ISD systems 
are useful to their current operations. 

D. RESEARCH QUESTIONS 

This thesis addresses the following primary research question: 

Primary question : What information sharing and discovery system elements do 
network-centric systems require to be valuable to the military missions of Network- 
Centric Warfare and Network-Centric Operations? 

To be able to answer the primary research question, several supporting questions 
need to be addressed and answered. These include, but are not limited to, the following 
subsidiary questions. 

Subsidiary questions : 

1. What is information sharing and information discovery? 

2. What are the generalized approaches to information sharing and 
information discovery? 

3. Why are information sharing and discovery services essential to network¬ 
centric systems? 

4. What are key concepts, terms, and definitions a person must know to 
understand information sharing and information discovery services? 

5. What is NCOW? How is information sharing and information discovery 
defined and used in NCOW? 
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6. From a systems engineering approach, what are the requirements and 
necessary capabilities for information sharing and discovery in network¬ 
centric systems? 

7. What services currently exist that enable information sharing and 
information discovery in network-centric systems? 

8. What are the current industry trends for future technologies in information 
sharing and discovery services? 

9. How can the DoD use emerging commercial industry trends to benefit 
their strategic mission? 

10. What NCOW information sharing and discovery issues must the DoD 
address in order to remain competitive against U.S. adversaries? 

11. What additional issues must be addressed to improve information sharing 
and information discovery in future network-centric systems? 

12. How should information sharing and discovery requirements guide 
acquirers, developers, and users? 

E. BENEFITS OF THE STUDY 

This thesis evaluates information sharing and information discovery in network¬ 
centric systems and discusses the relationship of these systems to NCOW. This study 
applies a systems engineering approach to establish requirements and initial design 
elements for future information sharing and discovery systems. The objective of this 
research is to provide guidance for the acquisition of future network-centric systems and 
component development. This study will also be used to develop Network-Centric 
Systems Engineering (NCSE) course material at the Naval Postgraduate School (NPS). 

F. SCOPE AND METHODOLOGY 

Research was conducted to reveal the brief history of NCOW in the DoD and to 
understand how the concepts of NCOW have transpired and been adapted in the current 
military strategy. A comprehensive review of the literature on the role of information 
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sharing and information discovery in various applications was performed to ascertain the 
importance of these processes to DoD endeavors. Interviews were conducted to support 
research on NCOW at the Defense Systems Information Agency (DISA) Customer 
Partnership Conference 2009, held 21-24 April, in Anaheim, California. Current and 
developing DoD systems and Web-enabled information sharing and information 
discovery services were examined to determine if these systems will meet the 
requirements of NCOW. The systems engineering design process was applied to produce 
a general ISD system design that includes: a set of operational concepts; an external 
systems diagram; a systems objective hierarchy; system requirements; a functional 
architecture; functional decompositions; and a requirements traceability matrix. 

G. ORGANIZATION OF THE THESIS 

This thesis is broken into five chapters: 

Chapter I discusses the background, motivation, purpose, research questions, 
benefits of the study, scope, and methodology of the thesis. 

Chapter II reviews the brief history of Network Centric Operations and the 
Network Centric Warfare model and it’s applications to current military doctrine. These 
concepts are summarized to highlight the importance of information sharing and 
information discovery to ongoing military strategic planning. 

Chapter III introduces the concepts of information sharing and information 
discovery, and defines these terms as the basis of this study. A survey of DoD 
information sharing and discovery systems is conducted to give the audience examples of 
current services available to warfighters. This chapter also discusses emerging industry 
trends for ISD systems and assesses their applicability to the DoD. 

Chapter IV uses a systems engineering approach to establish the operational 
concept of ISD systems and derive requirements for future acquisitions of ISD systems. 
This chapter also analyzes the interactions that ISD systems have with external systems, 
and discusses the importance of clear objectives during the conceptual phase. 
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Chapter V uses a systems engineering approach to establish a functional 
architecture for the ISD system. This chapter discusses the functions identified for the 
ISD system and presents the ISD system functional hierarchy. 

Chapter VI concludes the thesis by summarizing key points made throughout the 
study. This chapter also suggests several areas to conduct further research about ISD 
systems. 
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II. NETWORK CENTRIC OPERATIONS AND WAREARE 


Unless some type of network is created, sharing cannot occur. 

- Dr. David S. Alberts 

This chapter reviews the brief history of Network Centric Operations and the 
Network Centric Warfare model and their applications to current military doctrine. The 
main ideas of these concepts are summarized and discussed to highlight the importance 
of information sharing and information discovery to ongoing military strategic planning. 
The following sub-sections reveal how the Information Age has altered traditional 
military operations and discusses the concept of “information superiority” as it applies to 
current military strategy. This chapter also introduces the concept of the global 
information grid and net-centricity, and explains the role of information sharing and 
information discovery in network-centric systems. 

A. FROM INDUSTRIAL AGE TO INFORMATION AGE 

In 1996, the military was introduced to a new conceptual template called “full 
spectrum dominance” in the DoD publication, Joint Vision 2010 (United States Joint 
Chiefs of Staff 1995). The document, signed by then-Chairman of the Joint Chiefs of 
Staff Army General John M. Shalikashvili, defined full spectrum dominance as “the 
ability of US forces, operating unilaterally or in combination with multinational and 
interagency partners, to defeat any adversary and control any situation across the full 
range of military Operations”(United States Joint Chiefs of Staff 1995). Full spectrum 
dominance promoted a new theory of wartime dominance by advocating that the military 
focus on controlling all aspects of war, to include maritime space, air space, land forces, 
communications, and information contained within. This doctrine sought to create a 
template for how the DoD would “leverage technological opportunities” to conduct 
modem warfare. 

A 1998 U.S. Naval Institute Proceedings journal article Vice Admiral Arthur K. 
Cebrowski and John Gartska, entitled Network-Centric Warfare: Its Origin and Future 
discussed the characteristics of a new warfare doctrine called Network Centric Warfare 
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(NCW). This article was subsequently followed by a book published in 1999 by David 
Alberts, John Gartska, and Frederick Stein entitled Network Centric Warfare: Developing 
and Leveraging Information Superiority (Alberts, Garstka, and Stein 1999, 1-4). NCW 
expanded on many of the concepts that were covered in Joint Vision 2010. In the book, 
the authors advocated a new way of thinking about the battlefield and about fighting wars 
in the Information Age. Admiral Jay Johnson, the former Chief of Naval Operations, 
called it “a fundamental shift from platform-centric warfare” because the authors 
discussed the shift from the Industrial Age warfare to the Information Age (Alberts, 
Garstka, and Stein 1999, 16-17). This was a critical revelation because the focus of 
Industrial Age military doctrine was set upon the fighting platform. In contrast to this, 
the authors contended that the Information Age advocated a network-centric way of 
thinking. The network-centric concept suggested that military platforms were no longer 
the focal point in military operations but a node in a very intricate global network. 

Alberts, Garstka, and Stein suggested that adapting to the Information Age, and 
capitalizing on new information technologies (IT), could bring success to the U.S. 
military, as it had done with some commercial organizations. Figure 5 demonstrates the 
coevolution and shift to network-centric operations in commercial industry. 
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Figure 5. Coevolution and the Shift to Network-Centric Operations (From Alberts, 

Garstka, and Stein 1999, 28) 
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The authors analyzed the commercial sector to illustrate the potential the U.S. 
military had if they also capitalized on IT. Figure 5’s x-axis represents organizational 
change and processes occurring in commercial industry. The y-axis corresponds to 
technological innovations that are currently occurring (i.e., the shift from mainframes 
computers to personal computing to client-server communications). Established 
companies, with a strong competitive advantage in the marketplace, follow the 
“trajectory of innovation” represented by the dotted line (Alberts, Garstka, and Stein 
1999, 27-29). 

As illustrated in Figure 5, the authors pointed out that the commercial industry 
was leading the way in the Information Age and that the military could learn from their 
example. Information technology and the move to leverage information to use to their 
advantage enabled strong companies to continue to succeed. Successful industry 
corporations embraced new technologies and also committed to the organizational change 
necessary to aid the new needs of consumers. The companies that did not adapt to the 
Information Age fast enough were failing and being driven out (or acquired) by their 
more successful competitors. Alberts, Cebrowski, and Gartska drew parallels from the 
commercial sector into military warfare doctrine and argued that NCW was the military’s 
emerging theory of war in the Information Age (Alberts, Garstka, and Stein 1999, 25-27). 
In essence, the authors stated that NCW is the military’s answer to the Information Age. 
How, though, would the U.S. military be able to gain a competitive advantage? 

B. INFORMATION SUPERIORITY 

The way that U.S. defense forces will be able to achieve success in future 
endeavors against adversaries is to achieve Information Superiority. Information 
Superiority is “...a state that is achieved when a competitive advantage is derived from 
the ability to exploit a superior information position” (Alberts, Garstka, and Stein 1999, 
34) and is the basis that enables NCW to occur. It is a concept that depends on three 
characteristics of information: relevance, timeliness, and accuracy of the information 
presented. 
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As seen in Figure 6, the military (blue force) should strive to attain information 
that meet all three of the attributes (timeliness, accuracy, relevant information) and—at 
the same time—attempt to deny relevant information to adversaries (red force). 


% R#lpv;int Information 



% RH«vart Information 



Blue Force Capability 


Figure 6. Superior Information Position Vis-A-Vis an Adversary (From Alberts, 

Garstka, and Stein 1999, 56) 


Information superiority facilitates NCW and ensures combat power is achieved 
through (Alberts 2001): 

• Increased Shared Awareness 

• Increased Speed of Command 

• Higher Tempo of Operations 

• Greater Lethality 

• Increased Survivability 

• Streamlined Combat Support 

• Effective Self-Synchronization 

The notion behind information superiority, and the desire to attain it, is not a new 
wartime concept. The notion has been echoed by leaders throughout military history. In 
November 2003, for example, in Joint Operations Concepts, a United States Department 
of Defense, Director for Operational Plans and Joint Force Development document stated 
that “information superiority is an imbalance in one’s favor in the information domain 
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with respect to an adversary. The power of superiority in the information domain 
mandates that the United States fight for it as a first priority even before hostilities begin” 
(United States Department of Defense, Director for Operational Plans and Joint Force 
Development). 

The incorporation of the information superiority concept into the complex world 
we currently live in is, however, very new and very dynamic. The next step is to 
understand what tools are required to attain information superiority in the Information 
Age. 


C. THE GLOBAL INFORMATION GRID 

The network, and not the platform, is the focus of NCW. In the DoD the military 
network is referred to as the Global Information Grid, or more commonly, the GIG. 



Figure 7. Global Information Grid (From Defense Information Systems Agency 2009) 

The GIG defined as (Assistant Secretary of Defense for Networks and 
Information Integration/Department of Defense Chief Information Officer 2004): 
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The globally connected, end-to-end set of information capabilities, 
associated processes, and personnel for collecting, processing, storing, 
disseminating, and managing information on demand to warfighters, 
policy makers, and support personnel 

It is important to realize that the compilation of members, in the elaborate network that 
the GIG is comprised of, is more important than the individual components because 
interactions that occur between nodes are vital to the system. The synergy of network 
components enables the pursuit of Information Superiority to occur and achieve more 
than can be realized by individual elements. In other words, the well-known phrase “the 
whole is greater than the sum of the individual parts” certainly applies here. The GIG is 
the structure, which allows the DoD to communicate and share information relating to 
business, operations, and warfare. 

The network and the Information Technology found within the GIG are 
fundamental to NCW, therefore it is important to realize that the power of the network is 
found within the nodes that are included in it. To further elaborate on this concept, 
Metcalf’s Law (Figure 8) explains that each node in network of “N” nodes is capable of 
initiating “N-1” interactions. As the number of nodes increases (y-axis), the power of the 
network also increases (y-axis). 
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Non-linear relationship: 



123456789 10 

NODES 

Each node in a network of “N’ nodes is capable of initiating "N -1' interactions 

Total number of potential interactions between nodes in the network 

is: 
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3'2=6 Potential Information Interactions 


Figure 8. Metcalfs Law, Nodes vs Power (Top), Potential Information Interactions for 
N=3 nodes (Bottom) (From Alberts, Garstka, and Stein 1999, 33) 
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Therefore, the total number of (potential) interactions in a network is: A^*(A^-1), 

or - N. “Although the cost of deploying a network increases linearly with the 
number of nodes in the network, the potential value of a network increases (scales) as a 
function of the square of the number of nodes that are connected by the network” 
(Alberts, Garstka, and Stein 1999, 32). Thus, the capabilities of the GIG depend upon the 
number of the nodes that are connected within it and the interactions that occur between 
nodes. 

The GIG is continually evolving to increase the reach to entities that will be able 
to expand its capabilities by providing information. A powerful network is fundamental 
to Information Superiority because elements must be connected in order to contribute to 
the information fusion that creates the overall operation picture. 

D. NET-CENTRICITY 

The goal of the NCW and the GIG is to achieve a substantial DoD enterprise 
using Information Technologies. This network would be global, seamless, secure, and - 
most importantly—be available to warfighter when he or she needs it (Joyner 2005). The 
ultimate objective is to have ubiquitous access to information, so that users can access 
necessary information anywhere and at any time. This ambition is known as “net- 
centricity,” and is defined as (Defense Information Systems Agency 2009): 

The realization of a robust, globally interconnected, network environment 
(including infrastructure, systems, processes, people) in which data is 
shared timely and seamlessly among users, applications and platforms. By 
securely interconnecting people and systems, independent of time or 
location, net-centricity enables substantially improved military situational 
awareness and significantly shortened decision making cycles. Users are 
empowered to better protect assets; more effectively exploit information; 
more efficiently use resources; and unify our forces by supporting 
extended, collaborative communities to focus on the mission. 

The concept of net-centricity has been gaining momentum since its introduction 
in the mid-1990s. Former Secretary of Defense (SecDef) Donald Rumsfeld believed in 
the concept and worked hard to make it a priority during his time in office (Joyner 2005). 
He appointed retired Vice Admiral Donald Cebrowski, one of the authors of Network 
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Centric Warfare: Developing and Leveraging Information Superiority, as the director of 
the then newly formed Office of Force Transformation (Defense Information Systems 
Agency 2009). The Office of Force Transformation sought to implement NOW 
throughout the DoD and, although the office was disbanded soon after the death of 
Admiral Cebrowski, the concepts are still present in many military operations today. It is 
evident in many of the examples seen later in this research, that network-centricity is an 
implied goal of many systems currently being built for the DoD. Next, we look to 
understand what information sharing and information discovery contribute to network¬ 
centric systems. 

E. THE ROLE OF INFORMATION SHARING AND INFORMATION 

DISCOVERY IN NETWORK CENTRIC SYSTEMS 

To aid in understanding what NCW—and the power of a well-networked force— 
can accomplish for the DoD and the military, four basic tenets of NCW are introduced. 
These four tenets are (United States Department of Defense Office of Force 
Transformation 2005): 

• A robustly networked force improves information sharing 

• Information sharing enhances the quality of information and shared 
situational awareness 

• Shared situational awareness enables collaboration and self¬ 
synchronization, and enhances sustainability and speed of command 

• These, in turn, dramatically increase mission effectiveness 

These tenets describe how a warfighting force can develop and improve their 
power by drawing on the information provided by fully realized network. The NCW 
Hypothesis, shown in Figure 9, demonstrates a graphical view of the tenets of NCW as it 
traverses through the four domains of warfare: information, cognitive, social, and 
physical. 
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Figure 9. Tenets of NCW (From United States Department of Defense Office of Force 

Transformation 2005, 19) 

The NCOW doctrine requires the four warfare domains are considered when 
deciding on the attributes and capabilities of a military force. The information domain is 
the domain in which information is created and shared amongst forces. This domain 
includes sensors and processes that enable military units to establish communication 
among warfighters. The cognitive and social domains occur in the mind of the 
warfighter. It includes the leadership qualities a military member may possess, as well as 
experience with battlespace concepts and tactics. Human interactions also occur in this 
domain, as shared awareness and shared understanding of the situation takes place 
through collaboration among military units. Finally, in the physical domain, are where 
the more traditional aspects of military warfighting occur. This domain includes the 
environments (land, sea, air, space) where forces are able to use military platforms to 
achieve mission effectiveness (United States Department of Defense Office of Force 
Transformation 2005). 
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Information sharing, which lies in the information domain, is central to NCW’s 
hypothesis regarding sources of power. Once a comprehensive network is established, 
information sharing can occur and collaboration among different elements in a 
warfighting force with the same objective can take place. “The continuous sharing of 
information from a variety of sources enables the fully networked joint force to achieve 
the shared situational awareness necessary for decision superiority” (United States 
Department of Defense, Director for Operational Plans and Joint Force Development). 
Information sharing enhances shared situational awareness to other entities in the 
network. The eventual result of these processes, if successful, is an increase in mission 
effectiveness. 

This chapter introduced the concepts of NCOW by discussing the history of full 
spectrum dominance and the strategic changes that have evolved in the military from the 
Industrial Age into the Information Age. The concept of information superiority and the 
GIG, and their contributions towards achieving net-centricity, was also explained. 
Finally, the role of information sharing and information discovery in network-centric 
systems was explored to highlight the importance of these concepts to the DoD. The next 
chapter explains the importance of information sharing and information discovery and 
defines these terms for the remainder of this thesis. 
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III. OVERVIEW OE INEORMATION SHARING AND 
DISCOVERY SYSTEMS 


When information sharing works, it is a powerful tool. 

- National Commission on Terrorist Attacks upon the United States 

This chapter explains the importance of information sharing and information 
discovery and defines these terms as the basis of this study. Several concepts that 
contribute to information sharing and information discovery are discussed to give the 
audience background information and a framework for these (often) unfamiliar terms. A 
survey of DoD information sharing and discovery systems is conducted to give the 
audience examples of current tools and services that are available to warfighters. 
Upcoming industry trends are discussed to highlight the potential of future information 
sharing and discovery capabilities. 

A. INFORMATION SHARING 

Information sharing recently came into the spotlight due to the media attention 
the term gained during the work of the 9-11 Commission from 2002 to 2004. The 
National Commission on Terrorist Attacks Upon the United States (also known as the 9- 
11 Commission), “an independent, bipartisan commission created by congressional 
legislation and the signature of President George W. Bush” (National Commission on 
Terrorist Attacks upon the United States 2004), was tasked with conducting an extensive 
and complete investigation into the events that led to the infamous terrorist attacks on 
September 11, 2001. In addition to the full report, the Commission was also mandated to 
provide recommendations designed to guard against future attacks (National Commission 
on Terrorist Attacks upon the United States 2004). In their final report the Commission 
identified several pre-existing factors that led to the attack and made strong and specific 
recommendations to counteract future terrorist efforts against the United States. One 
such recommendation was that the government should focus more effort into creating a 
better system for agencies to share information with each other. The 9-11 Commission 
cited the lack of information sharing amongst government agencies as a contributing 
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factor the attacks and they proposed that reform occur in the government to enable 
information to “be shared horizontally, across new networks that transcend individual 
agencies” (National Commission on Terrorist Attacks upon the United States 2004). It is 
important for the government to draw upon the important lessons from the 9-11, such as 
how information sharing is significant to any operation, whether it is the defense of the 
country or commercial industry endeavors. 

Information sharing is an operational necessity that is not always planned for, but 
expected to occur. Often times, it is expected to happen seamlessly. Part of the reason 
may be that, not only is the term not well known, but it is also not well defined. 
Therefore, there is a problem when designing and implementing an ISD system. In spite 
of the importance of information sharing and information discovery, there is currently no 
specific guidance that identifies what ISD systems entail. There is an absence of basic 
elements of the systems engineering approach and design for ISD systems. As was seen 
in the previous chapter, an outline for the operational concept of ISD systems is 
discovered in the NCOW tenets. However, other elements necessary in the systems 
engineering approach are absent, such as: requirements; external systems context; 
interface guidance; and system architecture. Also, terms, definitions, and key concepts 
about the important elements of information sharing and information discovery are not 
standardized, so it is often hard for a user to comprehend what capabilities they need in 
an ISD system. Acquiring and/or developing ISD systems can, too, be difficult for DoD 
acquisition professionals because of the lack of collective DoD and industry terms and 
perceptions. 

Information sharing invokes a wide variety of definitions, all of which may be 
partially true. There are currently several synonymous meanings of the term. To share— 
to allow somebody or something to use something—has several meanings depending on 
what context a person is sharing. Objects, information, data, and knowledge can all be 
shared. There is an infinite amount of ways in which something, like information, can be 
shared. Information sharing protocols, such as extensible markup language (XML), 
simple object access protocol (SOAP), and Web services description language (WSDL), 
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are tools that allow structured information to be shared via the Internet. Or more simply, 
a discussion between people within an organization can enable information sharing, as 
well. 

The Department of the Navy Chief Information Officer’s (DON CIO) information 
sharing definition is used (Department of Navy Chief Information Officer 2008): 

Information sharing is making information available to participants 
(people, processes or systems). It includes the cultural, managerial and 
technical behaviors by which one participant leverages information held or 
created by another. 

Due to the completeness and applicability of this definition to the topics covered, 
this study continues to use the DON CIO’s definition of information sharing for the 
remainder of this research. The next section focuses on the difference between data, 
information, and knowledge, and explains how information enables action to occur. 

B. KNOWLEDGE HIERARCHY 

Information is fundamental to understanding any situation. This revelation allows 
us to appreciate why information sharing is absolutely crucial to successful military 
operations. When information is not shared there is no basis, or context, that a person 
may be able to relate to. Situational awareness is when information and knowledge about 
the perception of the environment is translated into a requisite level of common 
understanding across the spectrum of participants. Without the proper structure to share 
information, situational awareness is “lost”. Lack of information further complicates the 
circumstances of a situation, causing participants in a scenario miss key “pieces of the 
puzzle,” and hinders direct action to be taken. 

However, not all “information” is valuable and worth sharing and discovering. It 
is important to discuss what many academics refer to as the Knowledge Hierarchy 
(Nissen 2006, 16-17) when discerning if information will help a situation. Information 
can be shared and discovered at different levels and in varying degrees of abundance. 
This hierarchy attempts to model the hierarchy of data, information, and knowledge, and 
shows how each builds on the other. Figure 10 illustrates the Knowledge Hierarchy 
concept. 
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Figure 10. Knowledge Hierarchy (From Nissen 2006, 17) 

The Knowledge Hierarchy shows the complementary nature of data, information, 
and knowledge. Each component has unique characteristics, and relies on other elements 
to be useful (Nissen 2006, 17). 

The x-axis represents the abundance of the data, information, and knowledge. 
Data —facts, figures, text, and images—is the most abundant of the three levels, as it is 
relatively easy to acquire with today’s technological resources. Data is needed to 
produce information, which lies higher on the hierarchy. Information is produced when 
data is used in some context, or when there is meaning assigned to the data. Information 
enables a person to understand their environment and gives context to decisions that need 
to be made. Information along with other factors (education, experience, training) is 
necessary to produce knowledge. Knowledge is the most coveted of the three constructs 
because it supports action directly. The “?” at the level above the knowledge indicates 
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what some academics believe is another level of knowledge, such as: wisdom, 
intelligence, or enlightenment (Nissen 2006, 19). This study does not address this level 
as it is beyond the scope of our purposes. 

The y-axis of Knowledge Hierarchy represents the actionability of data, 
information, and knowledge. Of the three, data is the least actionable because it lacks 
background and meaning in a situation and is rarely enough to base a substantive action. 
Information is more likely to produce definitive action because contextual circumstances 
are available. Likewise, knowledge produces the most actionability because factors such 
as education, experience, and training, add value to the decision for action (Nissen 2006, 
21). All steps in the Knowledge Hierarchy (knowledge, information, and data) may 
enable a person to take some level of action. However, knowledge can enable a person to 
take direct action to progress a situation (Nissen 2006, 19). Of course, knowledge is 
usually more useful to have in a precarious scenario, such as during wartime. However, 
as Figure 10 illustrates, knowledge is harder to gain and much less abundant than data 
and information. This is because knowledge often requires many other factors that take 
time to acquire (i.e., experience or on-the-job training), so it is not practical to expect 
that knowledge will flow as fast as data and information can. 

Sharing and discovery occurs at each level of the Knowledge Hierarchy. This 
study is concerned with sharing information because it is the most realistic level we can 
hope to achieve with the unique constraints (time, environment, network, etc.) that are 
found in the DoD. Thus, it is important to understand how to ensure that information 
flows well throughout the DoD and military organizations. The next section will explain 
the concept of information discovery and discuss some examples of how information 
discovery is applied in the DoD. 

C. INFORMATION DISCOVERY 

The key benefit of information sharing is that it can lead directly to information 
discovery. Information discovery, much like information sharing, is a term that is often 
unclear. It is defined as: “browsing through collections returned by search engines, and 
forming collections of relevant results” (Kerne and Smith 2004). Information discovery. 
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in the context of this study, is characterized by iteratively reformulating problems, 
manipulating representations, and finding solutions and it often involves integrating 
multiple information resources (Kerne and Smith 2004). 

The type of information discovered depends substantially on the Community of 
Interest (COI) pulling or pushing (or providing/accepting or publishing/subscribing) the 
requested information. A COI is (Assistant Secretary of Defense for Networks and 
Information Integration/Department of Defense Chief Information Officer 2004): 

A collaborative group of users that exchanges information in pursuit of its 

shared goals, interests, missions, or business processes and therefore must 

have shared vocabulary for the information it exchanges. 

The role of the COI is to identify information gaps and direct information 
discovery. The COI (informally) defines the need for the information discovery that must 
occur. The intrinsic structure of the DoD reveals several COIs already “built-in” to the 
military organization. For example, the Navy has several warfare areas that comprise the 
overall mission of the service, such as: undersea warfare (USW); surface warfare (SW); 
anti-submarine warfare (ASW); and air warfare (AW). Each of these warfare areas can 
be considered a COI because the group of users within each warfare discipline is 
concerned with objectives specific to their mission. A user in the USW COI, for 
example, may not be necessarily interested in information that is discovered for a user in 
the ASW COI. 

COIs may be formulated at any level, and at varying capacities. If more 
granularity is necessary in a mission, lower-level COIs can be formed. Or, if a COI is 
needed that is comprised of several users from varying other COIs, a completely different 
(and specific) COI can be formed to meet that goal also. A COI exists if a collaborative 
group of users are exchanging information to pursue the same objectives. 

Discovered information is actionable, and defined by the needs of a COI. Next, 
we discuss how information sharing and information discovery are enabled by the use of 
information technology. 
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D. INFORMATION SHARING AND INFORMATION DISCOVERY IN THE 

NETWORK-CENTRIC WORLD 

Information sharing and information discovery can occur via different processes. 
Traditionally, information sharing was seen as an event that occurred between a sender 
and a receiver in a one-to-one relationship. The advent of information technology 
introduced several other sharing patterns: one-to-many, many-to-one, and many-to-many. 
The principles of information sharing and discovery, and the military objective of 
realizing a fully-functioning GIG, are centered on the concept of a successful ‘many-to- 
many’ sharing pattern. 

Information sharing and information discovery also occurs at different levels, 
depending on the scope of information that is necessary. In the case of the 9-11 
Commission, it was discovered that information sharing needed to occur at high levels 
between government agencies that had organizational knowledge of information leading 
to the attack. However agencies were not able (at the time), or were not aware that they 
should, share certain information with other agencies. Some information sharing occurs, 
on a smaller scale, as in between directorates, divisions, or personnel communicating 
information to advance their business. Whatever the scenario and the number of 
participants, at the backbone of information sharing and information discovery is the 
network that enables it to occur. Information technology, information systems, 
information communications, the internet, and Web-enabled services allow information 
to be communicated at an expedited rate and are the vehicles for information sharing and 
information discovery to transpire. 

In the article, “Findings of Network-Centric Systems Engineering Education,” 
Goshorn discusses the problems and needs for Network-Centric Systems Engineering 
(NCSE) education. The author defines four core approaches in the “network-centric 
world” that overlap each other, yet, have independent functions. The four overlapping 
approaches are: 
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Top-Down Approach 


• Bottom-Up Approach 

• Middle Approach of smart push/smart pull 

• Side View Approach 

These four overlapping approaches can be seen in Figure 11. The top-down approach 
includes the fundamentals of information sharing through the internet and enterprise 
services. The bottom-up approach covers the fundamentals of distributed systems and 
includes systems such as smart sensor networks. The middle approach connects the top- 
down and bottom-up and is the necessary link to push and pull information between these 
approaches. The side view approach extends communications to the tactical edge and is 
crucial for disadvantaged users to get their information (Goshorn 2008). 



Figure 11. The problems and needs discovered in the network-centric world (four 

overlapping approaches) (From Goshorn 2008) 
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Figure 11 shows that information sharing and information discovery reside in the 
top-down approach. In addition to the overlapping approaches, and to integrate the 
NCSE core, Goshom points out that the basis for all of the approaches (located at the 
trunk of the NCSE Core “tree”) are an understanding of the fundamentals of networking 
and communications. This NCSE Core allows the four approaches to function properly 
together. Erom a systems engineering perspective, a network-centric system must 
include all four approaches. Each approach can be viewed as a sub-system, or as a 
system, in a system of systems. This perspective is discussed and developed in chapter 
IV. 

E. INFORMATION SHARING AND DISCOVERY (ISD) SYSTEMS 

Information sharing and information discovery can occur at different levels and at 
varying capacities. The scope of this study focuses primarily on the type of information 
sharing and discovery that occurs via Web-enabled services and that encompass many of 
the elements seen in Figure ll’s top-down approach. Another aspect of the information 
sharing and information discovery is seen in Figure 12. 
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Figure 12. Information Sharing leads to Information Discovery 


Taking into account the four approaches introduced in the NCSE core, Figure 12 
illustrates that information sharing and information discovery are found in the top-down 
approach. The bottom-up approach contains the many devices and sensors that collect 
raw data. The middle approach embraces the actions taken via human, or through 
artificial intelligence, to move the data to venues that will allow processing, sorting, and 
filtering. The top-down approach is where the information sharing platform is located. It 
is made of an abundance of Web-enabled tools and services such as: wikis; blogs; Web 
portals; search engines; enterprise services; and collaborative tools. These tools form the 
foundation, or the information structure, for information sharing to occur. Subsequently, 
using systems within the information sharing domain enable COIs to discover 
information that is relevant to their mission. 
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Figure 12 will be referenced as a generalized ISD system model throughout the 
remainder of this thesis. Several of the concepts and examples surveyed in this study will 
map directly to the functions explained in Figure 12. 

With the basis of the top-down approach firmly established, the next section 
focuses on examples of DoD ISD systems being used at this time. 

F. EXAMPLES OF INFORMATION SHARING AND DISCOVERY TOOLS 

CURRENTLY IN USE BY THE DOD 

The concept of NCOW and the objective for the military to achieve net-centricity 
is outlined in Joint Vision 2010 (United States Joint Chiefs of Staff 1995) and the 
subsequent Joint Vision 2020 (United States Joint Chiefs of Staff 2000). These DoD- 
sponsored information guides discuss the military’s goals to become more network¬ 
centric and to achieve full spectrum dominance. In the endeavor to attain these 
objectives, the DoD has employed several systems that are capable of sharing and 
discovering information. 

The following sub-sections survey a sample of some of these DoD systems. Each 
example is described and examined to establish the relationship they have to the top- 
down approach (ISD system), seen in Figure 12 (Information Sharing leads to 
Information Discovery). 

I. FORCEnet 

The Navy, Marine Corps, and Coast Guard Team employ the network-centric 
system functional concept of FORCEnet for their 2E‘ century strategy. EORCEnet is the 
concept for naval command and control for joint operations and supporting activities in 
2015-2020. It is an innovation that is predicted to have dramatic and wide-ranging 
implications for the naval services because its intent is to establish a common direction 
for future naval command and control capabilities (Clark and Hagee 2005). An 
underlying premise of this operational construct and architectural framework is that 
EORCEnet will gets its power is the “network effect,” which causes the value of a 
product or service in a network to increase exponentially as the number of those using it 
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increases (Clark and Hagee 2005). This is the same notion that was previously described 
in Chapter II’s section regarding Metcalfs Law. 



Figure 13. FORCEnet Operational Concept (From Sharp 2003) 

In essence, FORCEnet is the Navy, Marine Corps, and Coast Guard’s answer to 
the naval implementation of the GIG. The Air Eorce and Army offer their own versions 
of the GIG with C2 Constellation Net (Air Eorce) and LandWarNet (Army). Eigure 13 
shows a broad view of what EORCEnet seeks to attain through the network of sensors, 
platforms, personnel, and information technologies. Since it is a representation of the 
GIG (on a smaller scale—for the Navy, Marine Corps, and Coast Guard), EORCEnet 
encompasses many elements from all of the network-centric approaches. Eor example, 
sensor networks and wireless communications are included from the bottom-up approach. 
The middle approach is seen in the exchange of information among sensors and 
platforms. The top-down approach can be seen in all aspects of Eigure 13, as well. The 
“communicating” realm of EORCEnet, which involves the movement of information, is 
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what is referred to in Figure 12’s information sharing platform. In addition, there are 
many COIs (logistics, warfare, intelligence gathering, etc.) within FORCEnet that direct 
the type of information discovery that is pertinent to the mission objectives that are being 
pursued. 

Central to the success to FORCEnet are the set of capabilities deemed as 
necessary to implement the concept. These are (Clark and Hagee 2005): 

• Provide robust, reliable communication to all nodes, based on the 
varying information requirements and capabilities of those nodes. 

• Provide reliable, accurate and timely location, identity and status 
information on all friendly forces, units, activities and 
entities/individuals. 

• Provide reliable, accurate and timely location, identification, 
tracking and engagement information on environmental, neutral 
and hostile elements, activities, events, sites, platforms, and 
individuals. 

• Store, catalogue and retrieve all information produced by any node 
on the network in a comprehensive, standard repository so that the 
information is readily accessible to all nodes and compatible with 
the forms required by any nodes, within security restrictions. 

• Process, sort, analyze, evaluate, and synthesize large amounts of 
disparate information while still providing direct access to raw data 
as required. 

• Provide each decision maker the ability to depict situational 
information in a tailorable, user-defined, shareable, primarily 
visual representation. 

• Provide distributed groups of decision makers the ability to 
cooperate in the performance of common command and control 
activities by means of a collaborative work environment. 
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• Automate certain lower-order command and control sub-processes 
and to use intelligent agents and automated decision aids to assist 
people in performing higher-order subprocesses, such as gaining 
situational awareness and devising concepts of operations. 

• Provide information assurance. 

• Function in multiple security domains and multiple security levels 
within a domain and manage access dynamically. 

• Interoperate with command and control systems of very different 
type and level of sophistication. 

• Allow individual nodes to function while temporarily disconnected 
from the network. 

• Automatically and adaptively monitor and manage the functioning 
of the command and control system to ensure effective and 
efficient operation and to diagnose problems and make repairs as 
needed. 

• Incorporate new capabilities into the system quickly without 
causing undue disruption to the performance of the system. 

• Provide decision makers the ability to make and implement good 
decisions quickly under conditions of uncertainty, friction, time, 
pressure, and other stresses. 


These capabilities require developmental efforts across six dimensions: physical, 
information technology, data, cognitive, organizational, and operating. Many of 
FORCEnet’s capabilities are seen as functions of the ISD system, discussed in Chapter V 
of this thesis. 


2. Net-Centric Enterprise Services (NCES) 

The DoD’s Defense Information Systems Agency (DISA) NCES has made great 
strides in enabling information sharing and discovery as a primary objective to connect 
systems that have information (data and services) with people who need information. 
This is a major principle of the top-down approach (Eigure 12) and of ISD systems. The 
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mission and vision of this NCES is to “enable the secure, agile, robust, dependable, 
interoperable data-sharing environment for DoD where warfighter, business, and 
intelligence users share knowledge on a global network” (Defense Information Systems 
Agency 2009). 

NCES consists of four primary product lines (Eigure 14): Collaboration; Content 
Discovery and Delivery; Portal; and Service Oriented Architecture Eoundation (SOAE) 
(Defense Information Systems Agency 2009). 
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Eigure 14. NCES Product Lines (Erom Defense Information Systems Agency 2009) 

In recent years, DISA’s products and capabilities have been steadily making their way 
into the hands of the military components. There have been increases in the use of the 
NCES product line as their resources are making life (and work) easier for end-users. 
The following sub-sections are a sampling of the more popular NCES procurements that 
have seen a recent rise in use: 

a. Defense Knowledge Online (DKO) 

As the DoD's enterprise portal, DKO provides users access to NCES, as 
well as a full suite of portal services. DKO was adopted and derived from the Army 
Knowledge Online (AKO) which is the Army's gateway to services, applications, and 
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content (NCES Website), because AKO is the largest of all the DoD portals (Jones 2007). 
The Navy and the Air Force have their own service portals as well: Navy Knowledge 
Online and the Air Force Portal. 


DKO offers the following services (Defense Information Systems Agency 

2009): 

• User Access to NCFS services including the DoD Collaboration 
Services 

• Organizational Web Sites and Folders (virtual spaces) 

• Team Sites and Personal Sites for File Sharing 

• Webmail (email address for life) with calendar 

• Groups - user or organizationally defined teams to support 
collaborative activities 

• Forums - threaded discussions 

• Single Sign On to hundreds of services and applications via DKO 
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• DKO Board of Directors Charter 

• DKO Policy • DKO Account Sponsorship 

• DKO Policy ■ DKO General User Guidelines 

• DKO Account FAQ 

NEWS 

• AKO/DKO Newsletter (ARCHIVE Page) 

• Early Bird 

• Defenselink DoD Top News 
t Defenselink Military News 

DoD Related 

• Defenselink Homepage 

• DoD Publications and Forms Page 

• National Defense Strategy 

PISA Related 

• DISA Home 

• DISROnline (CAC or soft-cert required for 
access) 

• DISA RACE 

TRAINING 

• AKO/DKO Training & Tutorials Page 

• : s'ense Language Institute (DU) 

• DU FREE online Language Materials 

• NEWI Defense Security Service Academv 

• CAC Resource Page (AKO) 

SECURITY 
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• . Demo 
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SEARCH 

• Defense Technical Information Center (DTICj 

• inteliry; 

• JEDS (Joint Enterprise Directory Service • DoD 
People Search) NOTE: CAC or Soft Cert required 
for access. 


WELCOME to the DKO Homepage! 




NEW! MyPay feature available to all Joint 
Services' 

Single Sign-on directly to myPay from AKO/DKO' I 
Click to single sign-on to inyPay now’ j 

(Note; you must have a myPay account. If you do 
not have an account, you will be asked to create 
one.) 

Click here to see a list of the AKO/DKO account 



^ dckoneof the menu bars below to finci out more about OKO 

About DKO DKO News DoD Retiree 


Welcome to the "DKO Dally" Channel! 


The intention of this channel is to provide regular, revolving, and useful information 
pertaining to AKO/DKO, The content in this channel will change regularly, so check it out 
dailyl 


Related or Subordinate Pages? 

What's the difference in the related pages? 

Have you ever noticed how under Related Content > Pages some of the pages have a different icon than 
the others? Some are related (horizontal) pages, and some are subordinate (vertical pages). What's the 
difference? Read the document Pages - Vertical or Horizontal Creation. 


Do you have something from your agency to share with the DKO 
community? Let us know; e-maii "dko.content@us.army.mir 


I Help us create a Great Homepage! 

I Provide your suggestions and feedback anytime’ We need your feedback to make this a site that you wa 
I contnue to use. Let us know what you tnnK 
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View all notifications (0 new) 


NEW IN MV FILES 
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View all new files 


Banned from using removable storage media in your Agency? 

Join the growing number of DKO users and post your documents on DKO. It's just like having your 
documents with you anywhere you go Simply load your files into a Knowledge Center on DKO — not 
only are they secure, but you can open them from any computer with an Internet connection. 

You can start immediately if you need 50 MB of storage or less. All DKO users have the ability create 
their own Site now' Sites contain a Group, Knowledge Center, and a Homepage. To create a site for you 
or your team now, click "create a site" at the top, right of any page and follow the prompts. When 
complete, you will have a place to store your documents, and a homepage Please see the DKO 
Training and Tutorials Page for helpful briefings on creating your own 'Team' or "Community" Site. 

Need more storage than 50 MB of storage? DKO can help Let us help you create an official 
"Organizational Site". Here's how. Click on the "Site Map'and expand "DoD Organizations'. Find your 
organization/agency and drill down to the lowest level you think your organization will fall under. Once 
you know the site map path for your organization, e-mail the path to "dko.content#us.army-mil" and 
we can help you set up an official site, including unlimited storage for you or your organization. 

For the FAQ on DKO accounts, click here. I 



Figure 15. AKO/DKO Web Portal (From Defense Information Systems Agency 2009) 

The DKO Web portal is an excellent example of the top-down approach 
and of an ISD system because it enables information sharing and information discovery 
through a variety of tools. DKO utilizes information sharing collaborative tools such as 
forums and email (a user may apply for their own email account through the site). It 
provides access to information repositories—compiled/stored information for users from 
various sources—for use in various mission areas. Likewise, it acts as a social 
networking site for members to engage in forums, online-discussions, and training. 
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This broad ISD system is meant for the all the users in the DoD (Army, 
Navy, Air Force, etc.). Thus, the portal has subsections that allow COIs to communicate 
with each other and discover necessary information regarding mission planning and 
command and control processes. 

b. Defense Connect Online (DCO) 

DCO is a commercially managed service that DISA acquired, from 
Carahsoft and partners Adobe and Jabber, to meet DoD collaboration requirements. It is 
an enterprise solution for collaborative internet protocol (IP)-based audio and video over 
IP conferencing (Department of Defense 2009). This Web conferencing tool allows other 
key features (Figure 16) such as shared desktop and embedded text chat functions, as 
well. 



Figure 16. DCO Desktop Sharing Mode (From Defense Information Systems Agency 

2009) 
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DCO is an example of a suite of collaborative tools with limited data 
storage. Like DKO, it has seen a surge in users recently because of the easy functionality 
of its services. Figure 16 provides a snapshot of a DCO common (home screen) 
configuration with chat, note pad, video/audio options, and member file sharing. DCO is 
an excellent collaborative tool that is gaining in popularity with users; however, it 
represents only a small portion of an ISD system’s functions. The system’s functions 
enable information sharing, but as Chapter V discusses, the ISD system also collects, 
processes, and distributes information relevant to the mission (information discovery). 
These are key functions that DCO does not deliver yet. Therefore, it is categorized as a 
collaborative tool only. 

c. Content Discovery and Delivery 

Of all of DISA’s NCES products, the Content Discovery & Delivery line 
is most aligned with the functions of the ISD system because it provides information 
advertisement, discovery, and efficiency. Content Discovery is concerned with 
enhancing the visibility of information products between the producers and the 
consumers of the GIG. This portion of the product line allows information producers to 
make their information available for discovery by COIs. The goals of this program are to 
increase information sharing and to increase overall awareness in the type of information 
available through DISA search tools: Centralized Search, Federated Search, and 
Enterprise Search (Defense Information Systems Agency 2009). 
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Figure 17. Content Diseovery Overview (From Defense Information Systems Agency 

2009) 


Content Delivery supports the delivery of information to users. Currently, 
this DISA NCES product line offers two content delivery capabilities: Enterprise Eile 
Delivery (EED) and GIG Content Delivery Service (GCDS). EED allows peer-to-peer 
file replication capability as a way to synchronize large file storage between 
geographically dispersed sites. GCDS is a commercially owned, globally distributed 
computing platform comprised of servers deployed across the Defense Information 
Systems Network (Defense Information Systems Agency 2009). This product is meant to 
provide information assurance and secure delivery of data to geographically separate 
COIs. 

The NCES’ Content Discovery & Delivery has many of the features of the 
ISD system, segmented into its different product lines. It is the basis of a good start for 
the GIG because the information sharing and discovery capabilities support the DoD data 
strategy to make information more readily available. Of all of NCES’ product lines. 
Content Discovery & Delivery caters the most to COIs. The search functions available in 
this product suite attempt to aid COIs that require extensive searching for mission 
information through the use of the Centralized Search, Eederated Search, and Enterprise 
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Search services. Likewise, EFD and GCDS support COIs in discovering information by 
making information assurance and delivery easier between them. 

There are currently several ISD tools available for use in the DoD. Each 
offers specific contributions to the network-centric top-down approach, and most 
products are still being operationally tested by the military services. Next, we look 
outside of the DoD, to examine existing industry developments that may provide value to 
future ISD system development and procurement. 

G. RELEVANT INFORMATION SHARING AND DISCOVERY INDUSTRY 

TRENDS AND DOD IMPLEMENTATION 

The DoD has capitalized on several information sharing and information 
discovery developments in recent years. However, there is a constant stream of new 
technologies in this field and, still, many more commercial advances that can be 
incorporated for use by the military. The commercial industry introduces innovative new 
concepts that may potentially change the composition of the military strategy and 
warfighting in the future. Some of the latest trends found in industry, of which many are 
already finding their way into DoD discussions, are summarized in the following 
sections. 

I. Service Oriented Architecture 

Service Oriented Architecture (SOA) has been a buzzword in the commercial 
information technology industry for a several years now because its principles are 
revolutionary. It is architecture for distributed systems based on common standards and 
practices and the loose coupling of services. The result of this architecture is the 
flexibility and agility of services that were not previously perceived as being 
interchangeable or reusable. SOA enables an environment that promotes information 
sharing by advocating using information technology systems that allow the using existing 
assets, rather than duplicating efforts within an organization. This concept promotes a 
way to easily facilitate changes that business may need to accommodate industry 
progression. The concept encompasses technological changes, as well as business 
changes (Hurwitz, et al. 2006). 
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Leveraging SOA in the DoD is a valid notion because the architecture attempts to 
close gaps in information sharing and information discovery by using common standards 
to exchange information and creating an information structure that is accessible to 
qualified users in the network. This differs from many of the existing legacy stove-piped 
systems that require specific and unique networks to operate and maintain. 

The concept of SOA and ISD systems complement each other well as the 
functions of the ISD system, discussed in more detail in Chapter V, mirror the basic 
principles of SOA. ISD systems provide relevant information from reputable sources and 
distribute data to users so that they may carry out their mission. Like the network-centric 
top-down approach, the objective of SOA is to be able to share common tools or services 
in order to facilitate mission effectiveness. For ISD systems, the common services are 
found in the information sharing platform (Figure 12). For SOA, the common tools are 
standards and services that may be utilized (and re-used) by several assets/systems. The 
industry standards introduced from SOA will aid in the current and future DoD design 
and acquisition of ISD systems. 

The following sub-sections further discuss the concept of SOA’s Enterprise 
Services (Bus), and will examine two examples of the SOA implementation in DoD 
applications. 


a. Enterprise Services 

Enterprise services, sometimes referred to as the Enterprise Service Bus, 
provide the software infrastructure that enables the use of SOA because it allows the 
integration and use of common components within an organization (Progress Software 
2009). The information sharing platform (Eigure 12) provides a similar aspect in the 
network-centric top down approach by acting as a repository of common services/tools 
that facilitate COIs in information discovery. The concept of net-centricity, discussed in 
detail in Chapter II, is analogous to enterprise services because each allows systems to 
provide necessary information to the right people ubiquitously. The enterprise service 
bus consists of the software components that direct information from one user to another. 
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Since the DoD community continually needs to share and retrieve information, enterprise 
services can provide the essential platform to combine internet technologies and the vast 
network power of the DoD. 

b. DISA NCES Service Oriented Architecture Foundation 

(SOAF) 

SOAF, another of DISA’s NCES product lines, aims to provide the 
network infrastructure for SOA to thrive in the DoD. The goals of the SOAF are to 
(Lewis 2006): 

• Provide the infrastructure to enable the evolution and operation of 
interoperable and secure service-oriented computing within the 
DoD and with partners and allies (Homeland Security, coalition 
partners, commercial industry) 

• Enable consumers to discover available services, determine which 
services meet their mission requirements, and securely and reliably 
consume them 

• Facilitate service providers’ ability to publish services, report 
appropriate performance information and dependably support their 
customers 

• Enable visibility into the performance of DoD enterprise services 
and their use in DoD mission and business operations 

• Enable asset management and visibility of enterprise services that 
exist on DoD networks or are being developed for DoD networks 

There are several SOAF Services (Figure 18): Enterprise Service 
Management, Machine-to-Machine Messaging, Service Discovery, Mediation, Service 
Security, and Metadata Services. In relation to the network-centric top-down approach 
(Figure 12), these services contribute to COEs capability to discover mission information 
by providing services that facilitate easier data search and publication. SOAF services 
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also monitor, manage, and support the transformation and exchange of computing 
services and data between users and their applications (Lewis 2006). 



Figure 18. SOAF Services (From Lewis 2006) 
c. CANES 

To combat the problem of supporting so many legacy systems, and in 
anticipation of rising maintenance costs of these systems, the Navy embarked on a new 
initiative that would implement SOA, as well (Turner 2007). The Consolidated Afloat 
Networks and Enterprise Services (CANES) program uses the principles of SOA to allow 
for open-architecture in fleet-wide, control, communications, computers, intelligence, 
surveillance and reconnaissance (C4ISR) capabilities networks by creating a common 
backbone with a common computing environment. The CANES common backbone is 
illustrated in Eigure 19. The objective of the CANES system is to replace various stove- 
piped afloat networks with a single, common network system. This is in direct contrast 
to the present jumble of systems which exist on present-day ships. If the objectives of the 
CANES system are met, it would significantly impact the Navy because there will no 
longer be a need to manage several complex systems (and the integration issues that 
accompany them). 
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Figure 19. CANES Common Backbone (From Turner 2007) 

The basic concept of CANES is to decouple the software from the 
hardware by permitting software updates without needing to outfit a platform new 
hardware to accomplish this. The primary goals of the CANES Program are to (Gourley 
2009): 

• Consolidate and reduce the number of afloat networks through the use of 
mature cross domain technologies and common computing environment 
infrastructure 

• Reduce the infrastructure footprint and associated costs for hardware 
afloat 

• Provide increased reliability, application hosting, and other capabilities to 
meet current and projected warfighter requirements 

• Federate Net-Centric Enterprise Services (NCES) Service Oriented 
Architecture Core Services to the tactical edge to support overall DoD 
C4ISR application migration to a SOA environment 

Since CANES is the Navy’s implementation of SOA, the program is 
related to the network-centric top-down approach and ISD systems in an equivalent 
manner. The objective of CANES is to be able to share common naval systems’ services 
in order to facilitate overall mission effectiveness. In ISD systems, the common services 
are found in the information sharing platform (Figure 12). In CANES, the common 
services are standards that may be utilized (and re-used) by several assets/systems. 
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Web 2.0 


Contrary to what the term may suggest, the phrase “Web 2.0” does not refer to a 
technical update to the existing version of the World Wide Web (WWW). Rather, Web 
2.0 is a term that conveys the collective changes in the usage of the WWW in recent 
years. Web development and Web design have been migrating to use of the internet 
network as a platform and focusing on services delivered over the Web platform 
(O'Reilly 2005). 



Figure 20. Web 2.0 (After Anonymous 2009) 


Like many newly introduced concepts, there is no concrete definition for Web 
2.0. Figure 20 illustrates some examples of Web 2.0’s primary conceptual changes. 
There is more social affiliation with the Web, especially through the use of social 
networking sites (Facebook, MySpace, You Tube, etc.). Internet users are also more 
participatory now, contributing information via blogs, online forums, and chat rooms. 
The Internet is seen more as a tool or application, then an entity. The term fundamentally 
refers to the change from static Hyper Text Markup Language (HTML) Web pages to a 
more dynamic WWW. This “newer internet” is organized and based on providing Web 
applications to users. Web 2.0 functionality also includes more open communication 
with an emphasis on Web-based COIs, and more open sharing of information 
(Anonymous 2009)Web 2.0’s features incorporate many of the fundamental principles of 
information sharing and information discovery systems (Figure 12). The new adaptation 
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of the WWW contributes to the information sharing platform by enabling users to 
collaborate and share information online. Likewise, Web 2.0 facilitates the organization 
of COIs (discussion groups, forum topics), so that information is more easily discovered 
when needed. The push toward open communication and two-way sharing support the 
ideals of NCOW and of ISD systems. 

3. Cloud Computing 

“Cloud computing” is a relatively new concept gaining recognition in many IT 
and computing communities. The term refers to a computing model instead of a specific 
technology. In the Cloud Computing model—the “cloud” is a metaphor for the 
internet—all servers, networks, applications and other components necessary to data 
centers are made available to users via the WWW (Fogarty 2009). 



Figure 21. Cloud Computing Model (After Hanna 2009) 


This computing model, shown in Figure 21, is significant because it does not 
require enterprise users to contract out these IT services to another entity. Instead, a 
business’ IT staff need only purchase the type and amount of computing services they 
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need from a company selling the three basic types of Cloud Computing: Software as a 
Service (SaaS), Platform as a Service (PaaS), or Infrastructure as a Service (laaS) 
(Fogarty 2009). Users are only required to “plug into” the cloud to access essential 
computing functions and to access their internal data center since this is where their 
information is stored, on servers belonging to the cloud-providing service. 

Cloud computing contributes to the information sharing platform (Figure 12) by 
providing services that enable COIs to store/retrieve information so that it may be shared 
and discovered by other COIs. There are also many of similarities between cloud 
computing and SOA as both concepts promote the re-use of tools and services to enhance 
the availability of information ubiquitously to all users. 

The cloud computing concept is so recent that the DoD has only just begun to 
debate its usefulness to the type of work that is done in the government. Of course, 
security is a primary concern because the basis of cloud computing requires that vital 
information be stored at a third-party facility in the conventional concept. There have 
been some discussions about creating a private cloud for the DoD to ensure that crucial 
data is protected from undesirable entities, but no tangible resolution has been reached. 

4. Open Source Software Development 

Another growing movement in computing and software development 
communities is the notion of delivering and deploying technology faster with the use of 
the open source software development. Open source refers to the availability of the 
computer source code for software. Users of open source software are allowed to use it 
as is, change it, or improve it for their own applications. The software can be 
redistributed freely, modified or not. The applications created by the software are 
potentially more useful and error-free over the long term. However, many professional 
developers also argue that the security of the code cannot be guaranteed free of harmful 
elements (backdoors, malicious code, etc.). 

Open source software development’s basic idea incorporates collaboration as the 
means for distributing source code. This contributes directly to the information sharing 
platform (Figure 12). Open source software development can enable information 
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discovery depending on the COI’s needs. Furthermore, future ISD systems may even be 
developed using some open source software, so it is important to comprehend key 
features of this growing trend in software. 


a. Forge.mil 

In February 2009, DISA released a program that would support the use of 
open source software in the DoD. The Forge.mil collaborative environment, shown in 
Figure 22, is the DoD’s approach to enable “rapid innovation to accelerate delivery of 
dependable software, services and systems to support net-centric operations and warfare” 
(Defense Information Systems Agency 2009). As illustrated in Figure 22, the program 
seeks to take tools, standards, and process from various sources (government, academia, 
industry) and re-use existing software and services to facilitate faster systems 
development efforts. SoftwareForge is the first component of Forge.mil’s family of 
services to be deployed. It provides integrated tools for project and idea collaboration, 
including source control, wikis, document storage, tasks, trackers, file release areas, and 
discussion forums. 
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Figure 22. Forge.mil Collaborative Environment (From Defense Information Systems 

Agency 2009) 
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The overall goals of the Forge.mil program are to (Defense Information 
Systems Agency 2009): 

• Enable cross-program sharing of software, system components, and 
services 

• Promote early and continuous collaboration among all stakeholder 
(e.g., developers, material providers, testers, operators, and users) 
throughout the development life-cycle 

• Rapidly deliver effective and efficient development and test 
capabilities for DoD technology development efforts 

• Help protect the operational environment from potentially harmful 
systems and services 

• Encourage modularity so that large programs to be developed, fielded, 
and operated as a set of independent components that can evolve and 
mature at their own rates 

• Eliminate duplicative testing and improve dependability by adopting 
common test and evaluation criteria supported by standard testing 
tools and methods 

In keeping with the basic principles of the network-centric top-down 
approach, Eorge.mil allows software developers access to tools that may help build 
network-centric systems. Usually, developers find it necessary to create their own 
environments in order to collaborate with other stakeholders of a program. This is a 
complicated undertaking, especially if project participants are geographically dispersed 
(Jackson 2009). Eorge.mil promotes information sharing with the existence of an on-line 
repository that can hold software code developed for the government and which can be 
reused by government according to the original licensing agreement. Often software is 
available for reuse, but other agencies do not know it is available. Information discovery 
is facilitated by the requirements defined by COI that software developers belong to. 
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Joint Vision 2010 (United States Joint Chiefs of Staff 1995) and Joint 
Vision 2020 (United States Joint Chiefs of Staff 2000) discuss the military’s goal to 
become network-centric and to realize the potential of NCOW. Since the time these 
DoD-sponsored information guides were published, the DoD has employed several 
systems that have some capacity to share or discover information. Additionally, a 
number of current industry developments have provided opportunities that may be useful 
to the military mission. Each system surveyed in the previous sections contains 
characteristics and/or contributes to basic principles found in the ISD system. Following 
the illustration of the NCSE top-down approach and the ISD system described in Figure 
12 (Information Sharing leads to Information Discovery), Table 1 clarifies some 
attributes of the ISD system that are mirrored in current industry developments and DoD 
implementations. 


ISD System Attributes/Provisions 

Examples of Implementations and 
Industry Developments with Similar 
Fundamental Characteristics 

- Means to collaborate with others, as 
needed for the mission 

- Collaborative Tools (i.e., DCO) 

- Web-enabled functions/services 

- Web Portals (i.e., DKO) 

- Use of an information sharing platform 
to share common services needed for the 
mission 

-SOA(i.e., CANES, SOAF) 

- Provides platform that assist users to 
discover information 

- Web 2.0 

- Allows storage/retrieval of information 
for users to access/provide information 
ubiquitously 

- Cloud Computing (SaaS, PaaS, laaS) 

- Collaboration is central to information 
sharing and discovery 

- Open Source Software Development 
(i.e., Forge.mil) 

- Use of COIs to facilitate appropriate 
information for the mission 

- DISA NCES Content Discovery and 
Delivery 
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- Contribution to the GIG (Network 
Effect) 


- FORCEnet (and other service 
component implementations) 


Table 1. ISD System Attributes/Provisions and Examples of Implementations and Industry 

Developments with Similar Fundamental Characteristics 

Following the functions of other similar collaborative tools, such as the 
DISA’s DCO, the ISD system provides a means to for users to collaborate with others 
(users, COIs) if needed for the mission. The ISD system’s Web-enabled tools/services 
are akin to those functions found in defense Web portals like DKO, AKO, and NKO. 
Also, the information sharing platform provides a repository of common services much 
as SOA provides the architecture for services to be utilized by different clients using the 
same basic tools. 

To discover information, the ISD system supplies an information sharing 
platform that aids COIs to find information specific their mission. This parallels the 
recent implementation of Web 2.0 and the view that many users now share, which is: that 
the WWW is now considered an application that can facilitate their search for 
information. Similarly, the ISD system shares some of the same basic principles as cloud 
computing because both allow storage and retrieval of information for users to access and 
provide information ubiquitously. 

The growth of open source software development (i.e., Forge.mil) is also a 
fundamental principle seen in the ISD system as it highlights that collaboration is central 
to information sharing and discovery. The use of COIs to facilitate delivery of applicable 
information to support various missions is comparable to the services provided by the 
DISA’s NCES Content Discovery and Delivery product because both attempt to link the 
correct publishers and subscribers to mission-applicable information. Finally, resembling 
FORCEnet (and other similar service component implementations), the ISD system 
attempts to contribute to the GIG and increase the network effect by connecting users 
with one another through information. 

Table 1 lists several ISD system attributes and provides examples of 
current implementations and industry developments that display comparable qualities. 

However, the implementations and developments listed may not be limited to just a 
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single contribution. Only key contributions are shown to highlight their similarities with 
the ISD system. The next section discusses how to apply the ISD system model to future 
network-centric developments. 

H. APPLICATION OF THE ISD SYSTEM MODEL 

It is important to realize that the concept of the ISD system is not an entirely 
separate concept from those systems surveyed in preceding sections and it does not offer 
new functionalities. Rather, the ISD system is a generalized model created using a 
systems engineering approach and it contains many similarities to the systems discussed 
previously. Its distinct contribution is that the ISD system model offers a means to map 
any information system (or sub-system or component), implementation, or concept onto a 
model that can relate it to the network-centric system. Figure 23 illustrates this notion 
with several of the systems surveyed earlier in this chapter. 



Figure 23. Mapping of Existing DoD Implementations and Industry Developments onto a 

Generalized ISD System Model 

Each of the current implementations and industry developments discussed earlier 
in this chapter were correlated to the generalized ISD system model. As a specific 
example, and to illustrate the idea further, the DISA’s Eorge.mil—an example of a DoD 
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implementation of the industry concept of open source software development—is 
mapped to the ISD system model in Figure 24. 
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Figure 24. Mapping of Forge.mil (Open Source Software Development) to the ISD 

System Model 


The recent DISA implementation of Forge.mil provides the capability to DoD 
software developers to share and reuse software. Information sharing occurs primarily 
through CTs, such as wikis, discussion forums, and file sharing tools. Information shared 
is dependent upon the specific COI, and is application dependant. There are numerous 
COIs because the software needed depends on the specific mission and/or the purpose of 
the COI. Information is discovered by the COIs in any of the four Forge.mil websites 
(software, project, test, certification) and is software is employed as needed. 

Any information system, implementation, or concept can be related to the ISD 
system model. Furthermore, as there continues to be new developments of information 
systems and technologies and as additional industry concepts emerge, this model can 
serve as an aid in understanding how a system contributes to the overall network-centric 
system by mapping the information sharing and discovery components. This is 
invaluable from a systems engineering point of view because there is currently no 
bounded system design for information sharing and discovery in a network-centric 
system, and no general systems engineering guidance for design and acquisition. With 
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this ISD system model and mapping, the top-down part of a network-centric system is 
generalized and bounded and allows mapping of any existing implementation onto it; 
therefore, this generic ISD System model is used to assist systems engineers in deriving 
requirements, designing the system structure, and implementing sharing and discovery 
systems in a network-centric system. Subsequent chapters of this thesis explain this SE 
process in further detail, with recommended external systems diagram, objectives 
hierarchy, requirements, and functional architecture. 

This chapter gave an overview of the concepts of information sharing and 
information discovery, and discussed the difference between data, information, and 
knowledge (Knowledge Hierarchy). The four network-centric approaches necessary to 
compose a network-centric system were also discussed to reveal that ISD systems reside 
in the network-centric “top-down” approach. An explanation of how information sharing 
leads to information discovery was conveyed to show that ISD systems consist of an 
information sharing platform and are facilitated by COIs that lead the information 
discovery efforts. A survey of several examples of current DoD ISD systems and 
relevant ISD trends was conducted to give a contemporary view of the state of the DoD’s 
acquisition of ISD systems. Finally, an explanation of how the ISD system model can be 
applied to any information system was discussed. The next chapter explores the 
importance of requirements in the Systems Engineering (SE) process and further refines 
the ISD system operational concept by applying the systems engineering process to 
design of the ISD System. ISD external systems are also discussed to aid in ISD system 
requirements generation. 
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IV. INFORMATION SHARING AND DISCOVERY SYSTEM 

REQUIREMENTS 


It's not enough that we do our best; sometimes we have to do what's required. 

- Winston Churchill 

This chapter summarizes and presents key products created in the process of 
deriving requirements for the ISD system. The discussions are separated into four 
sections. The first section discusses the importance of requirements in the systems 
engineering process and continues with the operational concept development that was 
introduced in previous chapters. The second section discusses the external system 
diagram created for the ISD system which bounds the system design problem and defines 
system interfaces. The third section introduces the concept of the systems objective 
hierarchy and addresses fundamental objectives for the ISD system. The fourth section 
proposes requirements for future ISD systems. The following chapter will further design 
the ISD system through functional architecture. 

A. IMPORTANCE OF REQUIREMENTS IN THE SE PROCESS 

The systems engineering process starts with requirements. Clear, well-defined, 
warranted, and attainable requirements from stakeholders in the system are essential to 
good design and the subsequent production of a system (Buede 1999, 119). Arriving at 
the right requirements is not an easy task. It is a continuous goal for systems engineers. 
If requirements are not well-written, the system risks not being a valuable asset to the 
stakeholders. Often, the end-user suffers (sometimes disastrous) consequences from the 
failure to produce an effective system. It is critical that system requirements are as 
complete as possible because “good” requirements are vital to the successful design and 
engineering of a system (Buede 1999, 119). 

B. EXTRACTING REQUIREMENTS 

There are several systems engineering (SE) models and the exact number of 

phases of the SE process differs based on the SE reference being used. With the 

exception of specific semantics, the phases are similar no matter which 
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organization is defining them. DoD Instruction 5000.02, the instruction which 
establishes the operation of the defense acquisition system, lists the following five 
life cycle phases (Department of Defense 2008): 

• Material Solution Analysis 

• Technology Development 

• Engineering and Manufacturing Development 

• Production & Deployment 

• Operations & Support 

A system’s life cycle is formed with the use of various types of different 
requirements. In this thesis, we are concerned with developing originating 
requirements —or those requirements that are developed in the context of mission 
requirements and focus on the boundary of the system (Buede 1999, 121). As seen in the 
Buede’s figure (25), requirements are organized hierarchically: 



Figure 25. Requirements Hierarchy (From Buede 1999, 122) 

Mission Requirements are defined in the context of the super system. In this 
thesis, the overall mission and the operational concept for ISD systems is summarized in 
Chapter I, Network Centric Operations and Warfare (NCOW). Originating requirements 
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fall beneath mission requirements and are not considered derived requirements, as are 
system requirements, component requirements, and configuration item requirements 
(Buede 1999, 121). 

This study subscribes to the seven functions that Buede presents as necessary for 
the originating requirements development process. These are: 

1. Develop Operational Concept 

2. Define system boundary with external systems diagram 

3. Develop system objectives hierarchy 

4. Develop, analyze, and refine requirements (originating and system) 

5. Ensure requirements feasibility 

6. Define the qualification system requirements 

7. Obtain approval of system documentation 

The focus of this study is on the first four of Buede’s functions. The preceding 
chapters began to develop the operational concept for ISD systems through discussions of 
the role of ISD systems in NCOW. We further refine the operational concept and define 
the system boundary of ISD systems via use of an external systems diagram. We also 
develop an ISD system objectives hierarchy to aid in summarizing stakeholders’ goals for 
the system. With the aid of the first three functions, and as seen in Figure 26, Buede’s 
fourth function is realized and originating requirements are developed for ISD systems. 


59 




Figure 26. Summary of originating requirements development (From Buede 1999, 159) 

The originating requirements identified in this study will aid in future 
procurement of ISD systems as it will provide acquisition professionals guidelines when 
identifying capability gaps and deriving requirements. The following chapter will further 
design the ISD system through functional architecture. 

C. IMPORTANCE OF THE OPERATIONAL CONCEPT 

According to Buede, the operational concept is a vision of what a system is, in 
general terms. It is a statement of mission requirements and a description of how the 
system will be used (Buede 1999, 139). The operational concept provides information 
about how the system will be employed from the perspective of its stakeholders and 
states the objectives of systems through a description of how the systems will fit into the 
stakeholders’ world (Buede 1999, 125). It is important to specify that requirements state 
the “what,” but not necessarily “how” requirements will be met. Those inner workings, 
the design of the system, are the responsibility of the engineers who are commissioned to 
construct the system after requirements have been established. 

The need and shared vision for ISD systems were covered substantially in 
chapters I and II. The overall mission of NCOW requires the capability to share and 
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discover information. In fact, information sharing plays a significant role in the basic 
tenets of NCW. To realize the new challenges that the Information Age poses to the 21^^' 
century military, it is imperative that the DoD define requirements for systems that bring 
the information sharing and information discovery capabilities to the DoD. The mission 
of NCOW requires that we have the resources to enable us to share information 
seamlessly. 

D. OPERATIONAL SCENARIOS 

The development of the operational concept started in chapters Till with 
exploration into the theory behind full spectrum dominance, information superiority, and 
how ISD systems contribute to NCOW. To expand on the operational concept 
development, the following sub-sections present several scenarios that illustrate “real- 
world” examples of use of an ISD system. Developing scenarios is a preliminary step for 
systems engineers to facilitate all stakeholders arriving at a universal definition of the 
system. Scenarios should not focus on how the system is processing inputs and outputs 
to the system, but instead they should focus on how the system is exchanging information 
(inputs, outputs) with other systems (Buede 1999, 140). 

Scenarios are classified into two categories: those scenarios that describe how a 
system will be used operationally, and scenarios that describe how a system will be used 
during other aspects of its lifetime (non-operationally) (Buede 1999, 140). Since this 
thesis is concerned about having the capability to share and discover information in 
support of mission operations, this study focuses only scenarios that deal with the NCOW 
operational mission and does not address the entire life cycle span of the ISD system. 
Scenarios and mission requirements for the development, manufacturing, training, 
deployment, refinement, and retirement of the ISD system are not included. The 
exclusion of non-operational scenarios is not limiting, as there is an abundant amount of 
operational applications for ISD systems. 
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1. Operational Scenario One: Combat Information Center Watch 
Officer Deployed on a Cruiser in the Persian Gulf 

A Combat Information Center Watch Officer (CICWO) deployed on a cruiser in 
the Persian Gulf is standing the 0400-0700 watch. In preparation to turnover to 
oncoming watchstanders, and to prepare for the daily morning brief to the Commanding 
Officer, the CICWO logs onto a secure Web portal to gather information about the events 
that occurred during her watch and events that will affect the Plan of the Day (POD). 
The Web portal, which is an element of the information sharing platform (Figure 12), 
offers her a large quantity of information about the events that will affect her command. 
The CICWO belongs to several COIs that pertain to her mission areas—intelligence, 
strike operations, 5* Fleet information, surface warfare operations—therefore, she is able 
to subscribe to information that is only relevant to her work. 

The CICWO pulls the following information: 

- News highlights from current events occurring in the United States and 
around the world 

- Intelligence Reports pertaining to the United States Central Command 
Area of Responsibility (AOR) and the Commander, U.S. 5th Fleet AOR 

- A copy of the Carrier Strike Group POD, including the carrier flight 
operations plan 

- The proposed transit plan of the oiler the cruiser intends to conduct a 
logistics replenishment with later in the afternoon 

2. Operational Scenario Two: Unified Combatant Command Desk 
Officer Preparing a Staffing Request 

A Unified Combatant Command desk officer has received direction from his 
superior officer to prepare a brief in preparation for a partner nation’s senior official’s 
visit. The desk officer has no experience in preparing this type of brief and is not given 
clarifying direction about his tasking. The desk officer refers to a host of information 
sharing tool/services (Figure 12) that may assist him with his new assignment. He logs 
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into a DoD personnel information website and, through his membership in a similar COI, 
discovers contact information of a counterpart at another Unified Combatant Command. 

After making initial contact with his counterpart, the desk officer discovers that a 
similar brief was given to the same partner nation’s senior official, and it was a successful 
presentation. The desk officer requests that his counterpart share the outline of his brief 
with him, so that he may duplicate the format for his own brief. Both officers, as well as 
a staff representative for the partner nation, meet via a Web-enabled collaborative 
technology to video teleconference and view the presentation together. The colleagues 
are able to share files with the use of a file-sharing tool available on the CT, as well. 
During the online meeting, the desk officer receives information about how to make his 
brief successful. His counterpart shares information about the aspects of the presentation 
that were well-received and the parts that were not favorable. The partner nation’s 
representative is also able to add insightful suggestions about what presentation topics his 
senior official will be interested in. 

3. Operational Scenario Three: Commander of Small Boat Security Unit 
Facing Immediate Threat 

The commander of small boat security unit for a naval installation is facing an 
immediate threat to the perimeter of the base. The suspicious watercraft his unit has been 
pursing is able to evade them in the darkness of the night, and the unit personnel have 
reason to believe that an unauthorized enemy diver has penetrated the base perimeter, as 
well. 

While onboard his patrol boat, the unit commander uses his handheld laptop to 
access an information sharing platform tool (Figure 12) and log in to the naval 
installation’s security Web portal. While attempting to relocate the suspicious watercraft 
and diver, he views raw data sent from various sensors located around the installation. 
Since he and his team belong to a maritime defense activity security COI, they are able to 
review (discover) live video streams from docked ship hulls and from cameras attached 
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to the underside of multiple piers. They have access to alerts from motion sensors in the 
immediate vicinity, and are able to pull information from audio sensors that have sensed 
abnormal background noise. 

The team’s membership in local law enforcement COIs allows them to discover 
information about how to contact local security officials and gain access to the 
information in their database and sensors. The fusion of this information allows the 
commander to deduce the correct location of the enemy watercraft and the small boat 
security unit is able to apprehend the suspects and the diver. 

E. DEPICTION OF THE ISD SYSTEM 

The ISD system is a human-designed system that consists not only of the system 
itself, but of internal systems and external systems (that affect and are affected by the 
system). All of these systems lie within a context. The context contains other systems 
that affect, but are not affected by, the ISD system. 

Figure 27 illustrates the ISD system and its relationship with other systems. The 
system is comprised of several internal systems that interact to form ISD system, these 
are: Processor, Support Personnel, Data Storage, Server, Database, and Computer 
Network. External systems, located within the dotted line, are a set of entities that 
interact with the ISD system via the system’s external interfaces (Buede 1999, 38). For 
the ISD system, the external systems are defined as: Bottom-Up System, Middle 
Approach System, User, and Side View System. External systems can impact the ISD 
system; however, the ISD system definitely impacts the external systems. All of the ISD 
system outputs flow to the external systems. Inputs to the system may come from the 
context entities or from the external systems. 
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Context 



The context of the ISD system contains the set of entities that may impact the system, but 
cannot be impacted by the system. The context consists of the: International Political 
Climate, National Military Strategy (NMS), Commercial Industry Technical Innovations, 
National Security Strategy (NSS), GIG, Foreign Adversary Strategies, and Environmental 
Factors systems. 

F. EXTERNAL SYSTEMS DIAGRAM 

To define the system boundaries, and to establish assumptions made for the 

design of the system, an external systems diagram is presented to show the boundaries of 

an ISD system. Every sub-system and component located on the inside of the system 

boundary is considered part of the system and is subject to change. Likewise, everything 

located on the outside of the system cannot be changed. The systems engineer is 

responsible for facilitating the process of establishing boundaries, which are defined by 

the stakeholders in the system with input from the procurers of the system (Buede 1999, 

144). More importantly, the external systems diagram illustrates the interactions between 
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the ISD system and external systems. Again, at this point in the ISD life cycle, the focus 
should be on the inputs and outputs of the ISD system and not necessarily on the internal 
workings of the system presented. It is important only to highlight the interactions our 
system has with other systems. 

Buede defines external systems as "entities that interact with the system via the 
system's external interfaces" (Buede 1999, 38). In the case of the ISD system, the 
following external systems and system functions exist: 


External Svstems 

Svstem Functions 

Bottom-Up System 

Provide smart sensor network 

Middle Approach System (Smart 
push/pull) 

Provide the ability to publish/subscribe to 
information 

Users 

Receive/process information and apply to mission 

Side View System (Disadvantaged User) 

Provide tactical smart information at the edge 


Table 2. ISD system external systems and functions 


Note that each of the ISD system’s external systems correspond to the network¬ 
centric approaches introduced in Figure 11. From a systems engineering perspective, a 
network-centric system must include all four approaches/systems. Therefore, the top- 
down (ISD) system, bottom-up system, middle approach system (smart push/pull), side 
view system (disadvantaged user), and users are considered systems, in the network¬ 
centric system of systems. 

In Figure 28, interactions between the ISD system and its external systems are 
traced for use during the operational phase of system. Inputs to the top-down (ISD) 
system (red lines) come from each of the external systems. The bottom-up system 
provides raw information and data that will be further processed in the top-down (ISD) 
system. Simultaneously, the ISD system pulls data and information from the middle 
approach system (smart push/pull). The side view (disadvantaged user) and user systems 
provide updated, corrected, and/or new data and information to the ISD system for 
further filtering and processing. 


66 




The top-down (ISD) system provides several outputs (green lines) to its external 
systems, as well. It provides pertinent information to the side view (disadvantaged user) 
and user systems for use in their respective mission areas. The top-down (ISD) system 
also supplies updated, corrected, and/or new data and information to the bottom-up 
system for use in updates to its sensor network. Finally, the ISD system pushes data and 
information to the middle approach system (smart push/pull). 

Additionally, there are several constraints (dotted lines) on all systems in this 
network-centric system of systems. These include, but are not limited to: data storage, 
computing network infrastructure support, security, information management, 
environmental conditions, and bandwidth. 

The interactions (inputs, outputs, constraints) between the top-down (ISD) system 
and its external systems will be used to help derive requirements for future ISD systems. 
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Figure 28. ISD System External Systems Diagram 


G. SYSTEMS OBJECTIVES HIERARCHY 

Another step in the effort to derive requirements for the ISD system is to compose 
an objectives hierarchy. The objectives hierarchy summarizes the goals “that are 
important to the systems stakeholders in a value sense.” This means that stakeholders 
should be able to pay to achieve increased performance, or decreased cost, as it pertains 
to the attributes cited in the objectives hierarchy (Buede 1999, 147). Some examples of 
the types of objectives that may be considered are: cost objectives, performance 
objectives, technical performance objectives, suitability objectives, schedule objectives, 
and risk objectives. 
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In the acquisition of the ISD system—a system that connects information sources 
and enables collaboration and information exchange to facilitate meeting critical mission 
requirements—our supporting objectives are to minimize the overall cost of the system 
and to maximize system performance. The systems objectives hierarchy, shown in 
Figure 29, illustrates the ISD systems’ supporting objectives and introduces subdivisions 
that contribute to the overall objective. Cost, for example, is divided into three types of 
expenditures: development, maintenance, and other life cycle costs such as operations 
and support and system disposal. System performance is composed of three attributes: 
security, functionality, and quality of the information. These attributes are further 
decomposed to assess other supporting objectives that contribute to the overall goal of the 
ISD system. 
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Figure 29. ISD System Objectives Hierarchy 


The purpose of the systems objectives hierarchy is to organize the “trade-offs” 
that need to be considered when deriving requirements for the ISD system. Since this 
study does not endorse a particular ISD system—and weights are highly dependent upon 
the mission area and unique constraints of a situation—the supporting system objectives 
and weights listed in Figure 29 are normalized. These system objectives are generalized 
and equally-weighted, therefore they can be applied to any ISD system and should be 
considered a template for further objectives to consider in specific ISD systems where 
weights may be adjusted accordingly. 
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H. TYPES OF REQUIREMENTS 

Defining requirements for an ISD system is based on information gathered from 
creating the operational concept development, the external systems diagram, and the 
objectives hierarchy. According to Buede, there are four requirement categories: 
input/output, system-wide and technology, trade-off, and qualification. 

1. Input/Output Requirements 

Input/output requirements are requirements based on “the basis of the inputs, 
controls, and outputs of the system” (Buede 1999, 153). When developing this set of 
requirements, the primary tool used is the external systems diagram because this product 
allows a view of system boundaries and interactions with external systems. Also, it is 
important to address the context (or environment) that the system is being used in these 
requirements. 

2. System-Wide and Technology Requirements 

System-wide and technology requirements pertain to the entire system, and are 
not limited to just interactions with external systems. These requirements often belong to 
more than just one requirement category, but can be distinguished this type of 
requirement because knowledge of the entire systems is required to determine if the 
requirement has been met (Buede 1999, 154). The objectives hierarchy aids in 
establishing these types of requirements and typically, every system-wide requirement 
should be addressed in this product. 

3. Trade-off Requirements 

Trade-off requirements are requirements that are based entirely on the 
stakeholders in the system. Each set of stakeholders possesses value judgments 
pertaining to the cost, schedule, and performance of the system. Depending on the 
stakeholder it may be easy to determine the value judgments; however, it is important to 
ascertain a good representation of all stakeholders’ judgments regarding the system. 
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4. Qualification Requirements 

Qualification requirements contain four elements for the systems life cycle: 
observance, verification plan, validation plan, and acceptance plan. Each of these phases 
has specific qualification criteria that need to be met. The observance phase pertains to 
how each of the input/output and system-wide requirements will be met. The verification 
plan phase addresses data that is used to ascertain if the system meets the expectations of 
system design. The validation plan data ensures that the system meets the goals of the 
originating requirements. The acceptance plan outlines data that will determine if the 
system is satisfactory for the users’ needs (Buede 1999, 156). 

1. ISD SYSTEM REQUIREMENTS 

Like the ISD system operational concept scenario development, the focus of this 
study is on the operational aspect ISD systems and on the first phases of the system 
engineering process (system definition and concept definition). Since this is a conceptual 
thesis and there is no specific ISD system being addressed. Therefore, the following sub¬ 
sections list recommended high-level requirements and contain little detail. It is assumed 
that the ISD system acquirers will be able to identify specific needs depending on the 
mission type and regard these requirements as an outline for their own systems. 

1.0 ISD System Originating Requirements 

1.1 Input/Output Requirements 

I. I. I Input requirements for operation 

1.1.1.1 The ISD system shall receive raw data and 
information from the bottom-up system. 

1.1.1.2 The ISD system shall pull information from 
the middle approach system (smart push/pull). 

1.1.1.3 The ISD system shall receive updated, new, 
and/or corrected information from the side view 
system (disadvantaged user). 

1.1.1.4 The ISD system shall receive updated, new, 
and/or corrected information from the user system. 
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1.1.2 Output requirements for operation 


1.1.2.1 The ISD system shall push data and 

information to the middle approach system (smart 

push/pull). 

1.1.2.2 The ISD system shall provide updated, new, 
and/or corrected information to the bottom-up 
system. 

1.1.2.3 The ISD system shall provide mission 

information to the user system. 

1.1.2.4 The ISD system shall provide mission 

information to the side view system (disadvantaged 
user). 

1.2 External Interface Requirements 

1.2.1 The ISD system shall interface with the bottom-up system. 

1.2.2 The ISD system shall interface with the middle approach 
system (smart push/pull). 

1.2.3 The ISD system shall interface with the user system. 

1.2.4 The ISD system shall interface with the side view system 

(disadvantaged user). 

1.3 System-wide and Technology Requirements 

1.3.1 The ISD system shall provide a means to connect 
information sources, enable collaboration, and promote information exchange to facilitate 
meeting mission requirements. 

1.3.2 The ISD system shall be designed to promote accessibility 
to information based on the user need, mission, and purpose of information sharing and 
information discovery. 

1.3.3 The ISD system shall be equipped with components that 
include a network backbone, software, and hardware necessary to process, receive, and 
provide information as defined by the user. 
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1.3.4 The ISD system shall organize raw data and information 
received in a logical format that promotes user-friendliness. 

1.3.5 The ISD system shall continuously renew existing 
information with updated, new, and/or corrected so user(s) have access to the most 
current information. 

1.3.6 The ISD system shall comply with the designated computer 
network and network infrastructure protocol. 

1.3.7 The ISD system shall have and provide, when accessed, 
informal training for new users. 

1.3.8 The ISD system shall comply with the designated 
communications protocols. 

1.3.9 The ISD system shall ensure information confidentiality, 
integrity, and availability is preserved through use of security tools designated by the 
appropriate directives. 

1.4 Trade-off Requirements 

1.4.1 The ISD system shall incorporate cost and performance as 
part of the tradeoff design. 

1.4.2 The ISD system shall incorporate security, functionality, 
and quality as parts of the performance tradeoff design. 

1.4.3 The ISD system shall incorporate development, 
maintenance, and other life cycle costs (such as operations and support and system 
disposal) as parts of the cost tradeoff design. 

1.4.4 The ISD system shall incorporate bandwidth, infrastructure 
support, network strength, technological advances, and environment as part of the overall 
system tradeoff design. 

1.5 Qualification Requirements 

1.5.1 The qualification system for the ISD system shall prove 
information sharing and information discovery pertinent to the mission. 
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1.5.2 The qualification system for the ISD system shall prove 
accessibility for COIs seeking to mission critical information. 

1.5.3 The qualification system for the ISD system shall prove 
that COIs will dictate information discovery. 

1.5.4 The qualification system for the ISD system shall prove 
value to the NCOW mission. 

This chapter summarized and presented key products created in the 
systems engineering process of deriving requirements for the ISD system. The 
importance of requirements was discussed and the operational concept further developed 
to highlight the role that ISD systems play in the NCOW mission. An external system 
diagram was presented to bound the ISD system design problem and define system 
interfaces. Also, a systems objective hierarchy addressed fundamental objectives for the 
ISD system. Finally, the last section in this chapter proposed originating requirements for 
future ISD systems. 

The next chapter will continue with the design by developing a 
functional architecture for the ISD system. 
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V. INFORMATION SHARING AND DISCOVERY SYSTEM 
EUNCTIONAL ARCHITECTURE 


Each new situation requires a new architecture. 

- Jean Nouvel 

This chapter summarizes and presents key products created in the process of 
developing a functional architecture for the ISD system. The discussions are separated 
into four sections. The first section discusses the requirement and process of developing 
the functional architecture of a system. The second section discusses the functions 
identified for the ISD system and presents the system functional hierarchy. The third 
section presents the development of the ISD system functional decompositions. The 
fourth section introduces a requirements traceability matrix to track requirements to 
elements of the ISD system’s functional architecture. 

A. THE ROLE OF FUNCTIONAL ARCHITECTURE IN AN ISD SYSTEM 

The functional architecture of a system characterizes what a system will do. It 
defines system functions and the information that flows between them (Buede 1999, 19). 
It is important for a systems engineer to spend an adequate amount of time thinking about 
the functions of the system and the relationship the activities have with one another 
because these interactions will ultimately dictate how successful the system is for the 
end-user. Defining the functions the system needs to perform is as important as the 
physical design of the system. In the process of architecting a system, the physical 
architecture and the functional architecture are both equally critical in eventually 
producing the operational architecture of the system (Buede 1999, 20). Figure 30 
illustrates the relationship the functional architecture and the physical architecture have in 
combining to produce a meaningful operational architecture: 
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Figure 30. Architecture development in the engineering of a system 

(From Buede 1999, 20) 

Due to the scope of this research, and the broad nature of ISD systems, this study 
identifies only critical aspects of the functional architecture. The physical architecture 
and operational architecture of the ISD system is left for continued research on the topic 
and is beyond the range of this thesis. The physical architecture is highly dependent on 
the mission of the organization designing it and specific details about the system type is 
left for further studies. According to Buede, the functional architecture may be revised 
several times as the operational architecture is being finalized. This study’s goal is to 
submit an initial and conceptual draft of a functional architecture that can eventually be 
combined with a physical architecture to produce the operational architecture of the ISD 
system. 

B. FUNCTIONAL ARCHITECTURE OF AN ISD SYSTEM 

A function is a process that takes inputs in and transforms these inputs into 
outputs (Buede 1999, 178). Each function has criteria for activating and for exiting the 
transformation—the change from one state to another—that is occurring. Buede states 
that a functional architecture can be defined at several levels of detail. The most 
common, however, is “a logical architecture that defines what the system must do, a 
decomposition of the system’s top-level function” (Buede 1999, 179). This functional 
architecture is most often represented as a directed tree. 
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Chapters II and III introduced the ISD system operational concept, and scenarios 
were presented to introduce the system and its objectives. The early stages in the life 
cycle introduced system functions that where simplistic and not well-defined. However, 
designing the functional architecture is characterized as the point in the system design 
process where “functionalities are created by shining a light into the black box” 
introduced earlier (Buede 1999, 180). The functionalities of the system are made even 
clearer with functional decomposition and/or composition. 

C. ISD SYSTEM FUNCTIONS 

I. ISD System Top-Level Functions 

The ISD system is unique because it is a system that may encompass several 
different services (Web portal, wiki, Web-enabled CT, etc.). These tools, elements in the 
information sharing platform (Figure 12), contribute the same basic functionalities to the 
ISD system. The information sharing platform permits COIs to discover information that 
will enable them to meet mission requirements. 

Regardless of the physical form of the ISD system, its essential objective is to 
share information so that users may discover information that will aid in successful 
completion of their mission. Figure 31 illustrates the top-level functions defined for the 
ISD system. (An ISD system full functional decomposition is presented in Figure 39, 
following explanations of each top-level function hierarchy.) 



Figure 31. Top-level ISD System Functions 
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The functional aspects of the ISD system were derived after focusing on the 
system’s objectives recalled from Chapter IV (Buede 1999, 187). Especially in defining 
top-level functions of a system, it is critical that a systems engineer use the overall system 
objectives as guide. This will enable the final product to be more efficient, and valuable, 
for the end-user. 

D. ISD SYSTEM FUNCTIONAL DECOMPOSITION 

The ISD system consists of seven top-level functions that aid in the overall 
objective to share and discover information. These functions enable the system to 
communicate information pertinent to the mission of the end-users, they are: 
Collect/Gather Information, Process Information, Organize Information, Filter 
Information Store Information, Present/Display Information, and Distribute Information. 

I. Collect/Gather Information 

The collection and gathering of data or information is a critical, initial function for 
the ISD system. This activity results in the ability of the other functions to contribute to 
the system. It involves the process of gathering data and collecting information for the 
system to work with and process accordingly. 



Figure 32. Functional Decomposition: Collect/Gather Information 


The second level of the functional decomposition is comprised of the activity of 
the system interacting with other external systems to gather information. This level of 
the decomposition is also concerned with differentiating the format, or communication 
protocol, of the information that is shared. 
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The third level of decomposition deals with the ISD system pulling information 
from various sources, such as various standalone databases and/or knowledgeable Web- 
based storage repositories. It also involves the process of receiving information 
(information push) from other sources—sources that are themselves, sharing information 
and dispersing it. Communication protocol is vitally important to the collection/gathering 
function because information is of no use to the ISD system if it is not in a format that is 
understandable to the system and the COIs. 

2. Process Information 

The function of processing information provides the widest scope of the functions 
of the ISD system because it involves the processes of information categorization and 
conversion. These are important activities for the ISD system because they will enable 
the system to fulfill further COIs requirements and requests for future information from 
end-users. If the data received is not able to be converted into a format that is accessible 
by the system, it cannot be presented to users for mission requirements. Likewise, if data 
received is not classified correctly, then it will be insignificant to the COTs mission. The 
second level of the Process Information functional decomposition addresses information 
categorization and conversion. 



Figure 33. Functional Decomposition: Process Information 
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The third level of the decomposition further catalogs information into subsets. 
Information is examined to determine if it is new/unprecedented information, a request 
for information (RFI), or an update to information that already exists in the ISD system. 
Data format is also detected to determine if the information is able to be converted to the 
ISD system format. 

3. Organize Information 

The function Organize Information is concerned with the classification of 
collected information and determining how data will be further processed. 



Figure 34. Functional Decomposition: Organize Information 


The second-level of the functional decomposition determines the type of 
information request that is presented. Further decomposition establishes if the requests 
pertains to a mission, determines if this is data that is frequently requested, classifies the 
request as administrative if the information pertains to the functions of the ISD system 
only, or will classify the request type as unknown if there is no appropriate 
categorization. 

Another second-level decomposition will determine the urgency and importance 
of the information. The third-level of this decomposition illustrates that the system 
determines the date and time of the request, establishes the classification of the 
information, or classifies the importance as unknown. 
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4. 


Filter Information 


The Filter Information function determines the future course of information in the 
ISD system. This is a critical function of the system as it will alleviate much of the risk 
the system has for accepting unwarranted, erroneous, and high-security risk information 
that may have been collected earlier unassumingly. This function disposes of information 
that may pose a risk to the ISD system, or will cause the system’s content to become 
discredited with wrong information. For the data which poses little security risk, and 
originates from credible information sources, this function allows the information to flow 
(to continue processing in the system). 



Figure 35. Functional Decomposition: Filter Information 


In the second-level of the decomposition, data can be discarded, or continue to be 
processed by the ISD system. The further decomposition of information to be discarded, 
establishes if the information request is outside the prescribed timeline, if the data is from 
a disreputable source, if the data is non-mission related, or if the data is erroneous. 
Information that proceeds for further processing is prioritized and tagged. 


5. Store Information 

The Store Information function allows the ISD system to store information that 
may be used for future COI RFIs, statistical data, or as a baseline for comparison to 
newly arriving data. 
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Figure 36. Functional Decomposition: Collect/Gather Information 

This function decomposes to a second level only and stores information based on 
if it is needed for long-term information requirements, or short-term RFIs. 

6. Present Information 

The top-level function Present Information is a critical activity of the ISD system 
as it affects the end-user more than any other top-level function. This function is 
essential for the human component (of the system receiving data) to discover information 
in a format that they can comprehend clearly. Since the ISD system is a networked 
and/or Web-based system, discovered information can be presented in two primary ways: 
visually and via auditory signals. This function enables the communication of data from 
the ISD system to the humans. The COI constituents, the human users, will use the 
discovered information to make crucial decisions about their mission. 



Figure 37. Functional Decomposition: Collect/Gather Information 
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The second-level of the Present Information function produces visual and 
auditory information for the users. Further decomposition of the visual display 
establishes the correct textual and picture displays to represent the information that needs 
to be conveyed. Sounds are also established to portray the audio signals that need to be 
shared. 


7. Distribute Information 

The Distribute Information function is the seventh and final top-level function for 
the ISD system. This function is concerned with the activities that determine which 
information to push or publish. Information to be published is converted to an output 
format specific to the ISD system. Also, information that is a recent version of stored 
data is used to update the information repository, as well as other similar information 
sources and systems. 



Figure 38. Functional Decomposition: Collect/Gather Information 


The second-level decomposition of the Distribute Information function 
determines if information is qualified to be published to users. Data is converted to an 
output format and also used to update existing information stored in the ISD system. 
Further decomposition establishes the correct receiving unit and categorizes if the 
distributed information is in response to an RFI. Data is also tagged to according to the 
specific ISD system’s specifications. If it is established that the data is necessary to 
update older (inaccurate) information, information sources are identified. 
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8. Full Functional Decomposition 

Figure 39, the ISD system full functional decomposition, illustrates the top three 
levels of the system’s functional decomposition. The top level starts with the ISD 
system’s primary functions and then partitions the functions into several sub-functions. 
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Figure 39. ISD System Full Functional Decomposition 
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E. TRACING REQUIREMENTS FOR THE ISD SYSTEM 

A Requirements Traceability Matrix (RTM) was the final step in producing the 
functional architecture of the ISD system. An RTM is an aid to ensure that the system’s 
requirements can be traced to the system’s functions, and vice versa. The traceability of 
functions and requirements provides a “valuable consistency check” (Buede 1999, 210) 
for the systems engineer to ensure that the system’s functional design is meeting the goals 
of the stakeholders. The functional decomposition of each top-level function was used to 
verify that requirements were met. 

Since the concept of the ISD system does not include the specificities of the 
physical architecture (hardware design, etc.), it is important to realize that the 
requirements and functions for the specific ISD system will vary widely. The mission 
set, itself, will incite many more comprehensive requirements. This study has 
endeavored to produce those requirements and functions that will be commonly found in 
any ISD system, however, the ultimate version will depend on the stakeholders in the 
actual process. Also, several iterations of the system requirements and architectures 
(functional, physical, operational) will transpire. The process to design the system will 
undergo many transformations, and require many versions of the products presented in 
this study. 

The RTM is divided into six sub-sections. Each section represents different types 
of requirements. Recall that the types of requirements we have introduced for the ISD 
system are: input/output, system-wide and technology, trade-off, and qualification 
requirements. 
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1. Requirements Traceability Matrix-Input Requirements 


Functions 

1.1.1. Input Requirements 

l.l.l.l. The ISD system shall 
receive raw data and information 
from the bottom-up system 

I.I.I.2. The ISD system shall pull 
information from the middle 
approach system (smart 
push/pull). 

I.I.I.3. The ISDsystem shall 
receive updated, new, and/or 
corrected information from the 
side view system (disadvantaged 
user). 

I.I.I.4. The ISDsystem shall 
receive updated, new, and/or 

corrected information from the 
user system. 

Collect/Gather Information 

X 

X 

X 

X 

Interact with external information systems 


X 



■Pull information 

X 


X 

X 

■Receive (pushed) information 

X 


X 

X 

Distinguish information sharing format/communication 
protocols 

X 

X 

X 

X 

■Confirm information sharing protocols within 
specifications 

X 

X 

X 

X 

■Identify information sharing protocols outside 
specifications 

X 

X 

X 

X 

Process Information 





Categorize information 





■Determine if new/unprecedented information 





■Determine if request forinformation (RFI) 





■Determine if information update 





Convert information to system format requirements 





■Detect present information format 





■Determine ability to use system information format 





Organize Information 





Determine Request Type 





■Establish if Mission Specific 





■Determine if Frequent Request 





■Classify as Administrative Request 





■Classify as Unknown Request Type 





Determine Urgency/Importance 





■Determine Date/Time of Request 





■Establish Classification 





■Classify as Unknown Urgency/lmportance 





Filter Information 





Discard Information 





■Establish if Outside Request Timeline 





■Determine if Disreputable Source 





■Classify as Non-Mission Related 





■Determine if Erroneous Data 





Continue to Process Information 





■Prioritize Information Request 





■Tag Data 





Store Information 





Classify for Long-Term Data Storage 





Classify as Short-Term Data Storage 





Present/Display Information 





Produce Visual Display 





■Establish Textual Display 





■Determine Need for Pictorial Displays 





Produce Audio Display 





■Establish Sounds 





Distribute Information 





Determine Information to Push 





■Establish Receiving Unit 





■Determine if Response to RFI 





■Tag Data to Push 





Convert Data to Output Format 





Update Exist!nginformation 





■Establish Information Sources to Update 





■Tag Data to Update 






Table 3. Requirements Traceability Matrix-Input Requirements 
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Requirements Traceability Matrix-Output Requirements 


Functions 

1.1.2. Output Requirements 

l.l.Z.l. The ISD system shall push data 
and information to the middle approach 
system (smart push/pull). 

I.I.2.2. The ISDsystem shall provide 
updated, new, and/or corrected 
information to the bottom-up system. 

I.I.2.3. The ISDsystem shall provide 
mission information to the user system. 

1.1.2.4. The ISD system shall provide 

mission information to the side view 

system (disadvantaged user). 

Collect/Gather Information 





Interact with external Information systems 





'Pull information 





'Receive (pushed) Information 





Distinguish Information sharing format/communication 
protocols 





'Confirm Information sharing protocols within 
specifications 





'Identify information sharing protocols outside 
specifications 





Process Information 





Categorize information 





'Determine if new/unprecedented information 





'Determine if request for information (RFI) 





'Determine if information update 





Convert information to system format requirements 





'Detect present information format 





'Determine ability to use system information format 





Organize Information 





Determine Request Type 





•Establish if Mission Specific 





•Determine if Frequent Request 





•Classify as Administrative Request 





•Classify as Unknown Request Type 





Determine Urgency/Importance 





•Determine Date/Time of Request 





•Establish Classification 





•Classify as Unknown Urgency/Importance 





Filter Information 





Discard Information 





•Establish if Outside Request Timeline 





•Determine if Disreputable Source 





•Classify as Non-Mission Related 





•Determine if Erroneous Data 





Continue to Process Information 





•Prioritize Information Request 





•Tag Data 





Store Information 





Classifyfor Long-Term Data Storage 





Classify as Short-Term Data Storage 





Present/Display Information 





Produce Visual Display 





•Establish Textual Display 





•Determine Need for Pictorial Displays 





Produce Audio Display 





•Establish Sounds 





Distribute Information 

X 

X 

X 

X 

Determine Information to Push 

X 




•Establish Receiving Unit 

X 

X 

X 

X 

•Determine if Response to RFI 

X 

X 

X 

X 

•Tag Data to Push 

X 




Convert Data to Output Format 

X 

X 

X 

X 

Update Existing Information 


X 



•Establish Information Sources to Update 


X 



•Tag Data to Update 


X 




Table 4. Requirements Traceability Matrix-Output Requirements 
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Requirements Traceability Matrix-External Interface Requirements 


Functions 

1.2. External Interface Requirements 

1.2.1. The ISD system shall interface with 
the bottom-up system. 

1.2.2. The ISD system shall interface with 
the middle approach system (smart 
push/pull). 

1.2.3. The ISD system shall interface with 
the user system. 

1.2.4. The ISD system shall interface with 
the side view system (disadvantaged user). 

Collect/Gather Information 

X 

X 

X 

X 

Interact with external information systems 

X 

X 

X 

X 

'Pull Information 

X 

X 

X 

X 

'Receive (pushed) information 

X 

X 

X 

X 

Distinguish information sharing format/communication 

X 

X 

X 

X 

'Confirm information sharing protocols within 
specifications 

X 

X 

X 

X 

'Identify information sharing protocols outside 
specifications 

X 

X 

X 

X 

Process Information 





Categorize information 





'Determine if new/unprecedented Information 





•Determine if request for information (RFI) 





•Determine if information update 





Convert information to system format requirements 





•Detect present information format 





•Determine ability to use system information format 





Organize Information 





Determine Request Type 





•Establish If Mission Specific 





'Determine if Frequent Request 





'Classify as Administrative Request 





'Classify as Unknown Request Type 





Determine Urgency/Importance 





•Determine Date/Time of Request 





•Establish Ciassification 





•Classify as Unknown Urgency/Importance 





Filter Information 





Discard Information 





'Establish if Outside Request Timeline 





'Determine if Disreputable Source 





'Classify as Non-Mission Related 





'Determine if Erroneous Data 





Continue to Process Information 





'Prioritize Information Request 





'Tag Data 





Store Information 





Classify for Long-Term Data Storage 





Classify as Short-Term Data Storage 





Present/Display Information 





Produce Visual Display 





•Establish Textual Display 





•Determine Need for Pictorial Displays 





Produce Audio Display 





•Establish Sounds 





Distribute Information 





Determine Information to Push 





•Establish Receiving Unit 





•Determine if Response to RFI 





•Tag Data to Push 





Convert Data to Output Format 





Update Existing Information 





•Establish Information Sources to Update 





•Tag Data to Update 






Table 5. Requirements Traceability Matrix-External Interface Requirements 
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Requirements Traceability Matrix-System-wide Requirements 



Table 6. Requirements Traceability Matrix-System-wide Requirements 
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Requirements Traceability Matrix-Trade-off Requirements 


Functions 

1.4. Trade-off Requirements 

LAL The ISD system shall incorporate cost and 
performance as part of the tradeoff design. 

LAZ. The ISD system shall incorporate security, 
functionality, and quality as parts of the performance 
tradeoff design. 

LAS. The ISD system shall incorporate development, 
maintenance, and other life cycle costs (such as operations 
and support and system disposal) as parts of the cost 
tradeoff design. 

l.AA The ISD system shall incorporate bandwidth, 
infrastructure support, network strength, technological 
advances, and environment as part of the overall system 
tradeoff design. 

Collect/Gather Information 

X 



X 

Interact with external information systems 

X 



X 

Pull information 

X 



X 

Receive (pushed) information 

X 



X 

Distinguish information sharing format/communication 
protocols 

X 



X 

'Confirm information sharing protocols within 
specifications 

X 



X 

'Identify information sharing protocols outside 
specifications 

X 



X 

Process Information 

X 


X 

X 

Categorite information 

X 


X 

X 

Determine if new/unprecedented information 

X 


X 

X 

'Determine if request for information (RFI) 

X 


X 

X 

'Determine if information update 

X 


X 

X 

Convert information to system format requirements 

X 


X 

X 

'Detect present information format 

X 


X 

X 

'Determine ability to use system information format 

X 


X 

X 

Organize Information 





Determine Request Type 





'Establish if Mission Specific 





Determine if frequent Request 





Classify as Administrative Request 





Classify as Unknown Request Type 





Determine Urgency/lmportance 


X 



Determine Date/Time of Request 





'Establish Classification 





Classify as Unknown Urgency/lmportance 





Filter Information 


X 



Discard Information 


X 



Establish if Outside Request Timeline 


X 



Determine if Disreputable Source 


X 



Classify as Non-Mission Related 


X 



Determine if Erroneous Data 


X 



Continue to Process Information 


X 



'Prioritize Information Request 


X 



Tag Data 


X 



Store Information 





Classify for Long-Term Data Storage 





Uassify as Short-Term Data Storage 





Present/Display Information 


X 


X 

Produce Visual Display 


X 


X 

'EstablishTextual Display 


X 


X 

Determine Need for Pictorial Displays 


X 


X 

Produce Audio Display 


X 


X 

'Establish Sounds 


X 


X 

Distribute Information 





Determine Information to Push 





Establish Receiving Unit 





'Determine if Response to RFI 





Tag Data to Push 





Convert Data to Output Format 





Update Existing Information 





'Establish Information Sources to Update 





Tag Data to Update 






Table 7. Requirements Traceability Matrix-Trade-off Requirements 
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6 , 


Requirements Traceability Matrix-Qualification Requirements 


Functions 

1.5. Qualification Requirements 

1.5.L The qualification system for the ISD 
system shall prove information sharing and 
information discovery pertinent to the mission. 

1.5.2. The qualification system for the ISD 
system shall prove accessibility for COIs seeking 

to mission critical information. 

1.5.3. The qualificationsystemforthe ISD 
system shall prove that COIs will dictate 
information discovery. 

1.5.4. The qualification system for the ISD 
system shall prove value to the NCOW mission. 

Collect/Gather Information 





Interact with external information systems 





■Pull information 





■Receive (pushed) information 





Distinguish information sharing format/communication 
protocols 




X 

■Confirm information sharing protocols within 
specifications 




X 

■Identify information sharing protocols outside 
specifications 




X 

Process Information 

X 




Categorize information 

X 




■Determine if new/unprecedented information 





■Determine if request for information (RFI) 





■Determine if information update 





Convert information to system format requirements 




X 

■Detect present information format 




X 

■Determine ability to use system information format 




X 

Organize Information 


X 



Determine Request Type 


X 



■Establish if Mission Specific 





■Determine if Frequent Request 





■Classify as Administrative Request 





■Classify as Unknown Request Type 





Determine Urgency/lmportance 


X 



■Determine Date/Time of Request 





■Establish Classification 





■Classify as Unknown Urgency/Importance 





Filter Information 





Discard Information 





■Establish if Outside Request Timeline 





■Determine if Disreputable Source 





■Classify as Non-Mission Related 





■Determine if Erroneous Data 





Continue to Process Information 


X 



■Prioritize Information Request 





■Tag Data 





Store Information 





Classify for Long-Term Data Storage 





Classify as Short-Term Data Storage 





Present/Display Information 


X 



Produce Visual Display 





■Establish Textual Display 





■Determine Need for Pictorial Displays 





Produce Audio Display 





■Establish Sounds 





Distribute Information 



X 


Determine Information to Push 





■Establish Receiving Unit 





■Determine if Response to RFI 





■Tag Data to Push 





Convert Data to Output Format 





Update Existing Information 



X 


■Establish Information Sources to Update 



X 


■Tag Data toUpdate 



X 



Table 8. Requirements Traceability Matrix-Qualification Requirements 

This chapter summarized and presented key products created in the process of 
developing a functional architecture for the ISD system. The reasons behind the need to 
develop a functional architecture of a system were discussed and functions were 
identified for the ISD system. An ISD system functional hierarchy was presented, 
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followed by ISD system functional decompositions. The last section introduced a 
requirements traceability matrix to aid in tracing requirements to elements of the ISD 
system’s functional architecture. 

The final chapter of this thesis will provide a research summary and present the 
conclusions of this study. 
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VI. CONCLUSIONS AND FUTURE RESEARCH 


Research is to see what everybody else has seen, and to think what nobody else has 

thought. 

- Albert Szent-Gyorgyi 

This chapter summarizes the research conducted throughout the course of this 
thesis. The need for information sharing and discovery systems is re-iterated because 
information plays an important role in today’s military environment. Key points for 
recommendation are also introduced to highlight potential areas for further research. 

A. RESEARCH SUMMARY 

To meet the challenges of the Information Age, the DoD needs to employ systems 
that are able to share and discover critical information to COIs efficiently. These 
systems—information sharing and discovery systems—are crucial to military operations 
because our strategic plans are only as good as the information that it is composed of. 
Likewise, information sharing and discovery are a central element in missions that 
employ network-centric operations and warfare, so it is imperative that the DoD is able to 
design and acquire ISD systems efficiently. 

The problem exists that there is currently no specific guidance that identifies what 
ISD systems entail. There is an absence of basic elements of the systems engineering 
approach and design for ISD systems, such as: an operational concept; requirements; 
interface guidance; and functional architecture. Therefore, it is often hard for a user to 
understand what an ISD system should be comprised of. It is even more difficult for 
DoD acquisition professionals to acquire or develop ISD systems because of the lack of 
systems design requirements. 

Chapter I of this thesis discussed the background and personal motivation of the 
study. The purpose, research questions, benefits of the study, scope, and methodology of 
the thesis were explored. 

Chapter II reviewed the history of network centric operations and the network 
centric warfare model and it’s applications to current military doctrine. These concepts 
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were summarized to highlight the importance of information sharing and information 
discovery to ongoing military strategic planning. 

Chapter III introduced the concepts of information sharing and information 
discovery, and defined these terms as the basis of this study. A survey of current DoD 
ISD systems was conducted to give the audience examples of services available to 
warfighters presently. This chapter also discussed emerging industry trends for ISD 
systems and assessed their applicability to the DoD. 

Chapter IV used a systems engineering approach to refine the operational concept 
of ISD systems and derive requirements for future acquisitions of ISD systems. This 
chapter also analyzed the interactions that ISD systems have with external systems, and 
discussed the importance of clear objectives during the conceptual phase. 

Chapter V used a systems engineering design approach to establish a functional 
architecture for the ISD system. This chapter discussed the functions identified for the 
ISD system and presented the ISD system functional hierarchy. 

This chapter (VI) concludes the thesis by summarizing key points made 
throughout the study. This chapter also suggests several areas to conduct further research 
about ISD systems. 

B. KEY POINTS OF THE STUDY 

This thesis was built upon Goshorn’s network-centric top-down approach (Figure 
11), to demonstrate the elements of the ISD system. ISD systems include the 
information sharing platform, which is made from an abundance of Web-enabled tools 
and services such as: wikis; blogs; Web portals; search engines; enterprise services; and 
collaborative technologies. These tools form the foundation, or the information structure, 
for information sharing to occur. Subsequently, using systems within the information 
sharing domain enable COIs to discover information that is relevant to their mission. 
Information discovery enables COIs to take action to advance their mission objectives 
and overall effectiveness. Figure 12 was central to this study as it presented a generalized 
model based on the (four) network-centric approaches and explained how information 
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sharing leads to information discovery in an ISD system. This ISD system model was 
used to examine several current ISDs, and forms the basis of the system architecture 
presented in Chapters IV and V. 

Having established the basis of ISD systems, and after exploring the definition of 
information sharing and information discovery, this study applied the systems 
engineering process to the design of ISD systems. Several key elements of the systems 
engineering approach were introduced for ISD systems. An operational concept was 
refined, requirements were generated, and a basic functional architecture was presented. 

C. AREAS FOR FURTHER RESEARCH 

There are numerous areas that can be researched to further enhance this thesis. 
The bulk of these are found in Chapter Ill’s exploration of ISD tools currently in use by 
the DoD and relevant ISD industry trends. Time constraints and the scope of this thesis 
permitted only a survey of these systems, but any of the topics under these sub-sections 
can be investigated with more detail. 

This thesis applied the systems engineering approach to a generalized ISD system, 
and presented a template of factors to consider when designing a real ISD system. This 
was organized in this manner with the understanding that this thesis would be used as a 
basis for guidance during the acquisition of an actual ISD system. Further research can 
be conducted on ISD systems with specific objectives and for detailed warfare missions 
(i.e.. Maritime Domain Awareness, Undersea Warfare, Anti-Submarine Warfare). 

D. FINAU SUMMARY 

Information is a key component to successful military planning and operations 
because it produces knowledge and enables action to occur. Therefore, today’s military 
professional requires current, relevant, and credible information to be able to sustain the 
transforming warfare environment. This is not a simple task in the modem national 
defense setting. The advent of information technologies, and the abundance of 
information, has introduced an entirely new set of conditions that must be met in order to 
remain competitive against our adversaries. With this in mind, it is imperative that the 
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DoD is able to acquire ISD systems that are capable of sustaining the military through the 
Information Age and into the next revolutionary era. National defense requires that we 
not only keep abreast of the dynamic world we live in, but that we are also able to see the 
entire context of the problem (or system). 
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